[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Using sgid binaries to defend against LD_PRELOAD/ptrace()

Hi all,

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

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.

This problem has become more pressing with the advent of PolicyKit,
where even fewer processes have the in-built privilege separation
between root and users. Getting rid of a lot of instances of
gksu/kdesu is great, of course. :) [1]

This concerns a scenario where you might have a rogue trojan in your
session (e. g. a malicious firefox plugin or an autostart shell
script). Admittedly, if an attacker gets that far he has almost won
the machine and can easily get more privileges with some social
engineering and spoofing, but I feel it is worth the small effort to
at least not allow reading passwords from other processes' memory
without making any noise at all.

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
new static group into base-passwd, like "noptrace", to not abuse
existing groups and not confuse auditing tools.

Setgidness provides a robust way to disallow ptrace/LD_PRELOAD for
the user's peer processes without disabling them in general. (Note
that all attempts to disable ptrace() within the program itself, such
as prctl(SET_DUMPABLE, 0) are subject to race conditions and won't

Another option would be to introduce a sysctl for enabling ptrace for
users and disable it by default, but that would just mean that every
developer get immediately frustated about gdb not working and enable
it again at instant, so that you don't end up with any protection at
all. Providing the sysctl would be useful anyway for servers, but
disabling it by default is a bad idea I think.

So I am asking for the addition of a new static group with this
purpose. Once we have that, we can convert specific packages to use
that setgid trick.

What do you think about this approach? I'm well aware that this alone
won't rescue desktop security (getting there is looots of more work),
but one has to start somewhere.

Thanks in advance for any comments,


P.S. Please keep me in CC.

[1] gksu's security properties are just *so* horrible... That program
is a mess. (I haven't looked at kdesu, but I guess it's not much

Martin Pitt        http://www.piware.de
Ubuntu Developer   http://www.ubuntu.com
Debian Developer   http://www.debian.org

Attachment: signature.asc
Description: Digital signature

Reply to: