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. 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 help). 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, Martin 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 better) -- Martin Pitt http://www.piware.de Ubuntu Developer http://www.ubuntu.com Debian Developer http://www.debian.org
Attachment:
signature.asc
Description: Digital signature