Re: Using sgid binaries to defend against LD_PRELOAD/ptrace()

[Goswin von Brederlow <goswin-v-b@web.de>]

Josselin Mouette <joss@debian.org> 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
>> 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?

>> 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?
>
> Cheers,

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.

MfG
        Goswin