Re: Using sgid binaries to defend against LD_PRELOAD/ptrace()
On Sun, Apr 27, 2008 at 12:56:28PM +0200, Goswin von Brederlow wrote:
> Josselin Mouette <joss@debian.org> writes:
> > Le vendredi 07 décembre 2007 à 19:18 +0100, Martin Pitt a écrit :
> >> one thing that has bothered me for a long time already is the
> >> complete lack of a security boundary between processes of the same
> >> user. Things like LD_PRELOAD and ptrace() (IOW, gdb) are enabled by
> >> default for all users, and especially for developers this is a good
> >> thing.
> >>
> >> However, a lot of programs that we have deal with passwords and other
> >> secrets which deserve some protection, like passwords you type into
> >> ssh, screensavers, seahorse, etc.
> >
> >> One easy solution that comes to my mind is to install those affected
> >> programs setgid, and drop the additional group immediately after
> >> program start with setgid(getgid()). For this we should introduce a
>
> Can one trace a sgid programm after it has dropped the group?
No; see kernel/ptrace.c:__ptrace_may_attach().
> >> new static group into base-passwd, like "noptrace", to not abuse
> >> existing groups and not confuse auditing tools.
> >
> > Given that it seems unlikely that we obtain another solution, should we
> > start right now with that stuff?
> >
> > Colin, as base-passwd maintainer, do you have anything against creating
> > such a group?
>
> Can't you do something against ptrace in the binary itself and only
> for critical sections?
You can (use prctl() to disable PR_SET_DUMPABLE), but it's only checked
on ptrace_attach so that would be racy. In any case, there are programs
such as ssh-agent that intentionally keep secrets around for a long
time, not just during critical sections. (ssh-agent is already setgid
ssh to prevent attacks on this.)
> No idea how to prevent LD_PRELOAD and people could always use their
> own linker to ignore the sgid bit anyway.
If they want to deliberately start a program with reduced protection and
then type their password into it, then that's their (foolish) choice.
The point of this is so that processes started in good faith can't have
their memory inspected so easily later on.
--
Colin Watson [cjwatson@debian.org]
Reply to: