Re: Using sgid binaries to defend against LD_PRELOAD/ptrace()
Josselin Mouette <email@example.com> writes:
> Le vendredi 07 décembre 2007 à 19:18 +0100, Martin Pitt a écrit :
>> 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.
>> 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?
>> 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?
No idea how to prevent LD_PRELOAD and people could always use their
own linker to ignore the sgid bit anyway. Seems silly to block that as
it can't exploited between unrelated binaries.
But for ptrace I would rather introduce PTRACE_HIDE_TRACEME,
PTRACE_SHOW_TRACEME for temporary disabling and PTRACE_DONT_TRACEME
for permanent disabling.