| |||||||||||||
Filesystem capabilities in Fedora 10Filesystem capabilities in Fedora 10Posted Jan 8, 2009 8:01 UTC (Thu) by asamardzic (guest, #27161)Parent article: Filesystem capabilities in Fedora 10
I'm really unable to see any advantage of this and alike approaches over plain fixing program(s) in question to execute under superuser UID only during sequences of code where superuser privileges needed.
(Log in to post comments)
Filesystem capabilities in Fedora 10 Posted Jan 8, 2009 8:46 UTC (Thu) by jamesh (guest, #1159) [Link]
The rationale goes that an application can't be exploited to do things it never had permission to do in the first place. The setuid bit gives an app a lot of permissions (even if it changes its effective UID when it doesn't need them).
In contrast, if the app only has the capabilities it needs you can only exploit those capabilities. So a bug in ping might only allow creation of raw sockets, but not bypass of file system permissions.
Filesystem capabilities in Fedora 10 Posted Jan 8, 2009 13:05 UTC (Thu) by asamardzic (guest, #27161) [Link]
The code in a SUID application could at will switch, through setuid(2), between real and saved set-user-ID. So in this particular case, it should be possible to switch back to real user ID immediately upon program started and go this way until socket(2) call needed to open the raw socket. Just before this call, setuid() should be called to switch to saved set-user-ID (which means to switch to superuser privileges), and immediately after socket() returned the descriptor, setuid() should be employed again to switch back to real user ID (which means to return to executing as ordinary user). And that's the whole magic. Now, I'm pretty sure that things are not actually that simple in the ping source code, but still I fail to see what advantage this complicated capabilities mechanism could have over careful code examination, and applying proved techniques as this one I tried to describe above.
Filesystem capabilities in Fedora 10 Posted Jan 8, 2009 14:27 UTC (Thu) by vonbrand (subscriber, #4458) [Link]
The problem is that malicious code that somehow subverted
Filesystem capabilities in Fedora 10 Posted Jan 9, 2009 6:53 UTC (Fri) by yvesjmt (subscriber, #38201) [Link]
I believe you're referring to seteuid(2) instead. The syscall you mentioned, setuid(2), makes a permanent change, because it sets the real and effective user IDs, and the saved set-user-ID.
Using seteuid(2) won't help. If the code can switch back to the saved set-user-ID and it gets exploited, it's rooted. No security added here.
If ping needed to open the raw socket only once, it could drop privileges permanently. But as we know ping needs to open sockets continuously.
> Now, I'm pretty sure that things are not actually that simple in the
Even if you do "careful code examination" when writing programs, that's not a replacement for good a security design. You'd still need other layers to protect from subtle issues[1].
One of the mantras of writing secure software is giving the least privilege necessary. That's what capabilities is about - though I confess I had never heard about them.
[1] I'd recommend this wonderful short book that covers this topic really well http://oreilly.com/catalog/9780596002428/
Filesystem capabilities in Fedora 10 Posted Jan 9, 2009 15:44 UTC (Fri) by jwarnica (subscriber, #27492) [Link]
If everything works well... then everything works well. You might as well not have the concept of user accounts, just have everything run at the same level. Just audit all your source code with proven techniques, and all is good. If everything works well.
Filesystem capabilities in Fedora 10 Posted Jan 8, 2009 13:48 UTC (Thu) by elanthis (guest, #6227) [Link]
In order for a program to get superuser privileges it must already have superuser privileges. The alternative is to break apps up into two parts -- the frontend and the secured backend -- but that is neither practical for many projects nor actually a complete solution. If _any_ part of the program runs setuid then there is an opportunity for exploit. If _no_ part of it runs as setuid, then there essentially is no opportunity.
That is what capabilities are for. Give the program only what it needs and nothing else. You can take it a step further and split the program into frontend and backend pieces and give only the backend piece the capability necessary, too.
Filesystem capabilities in Fedora 10 Posted Jan 8, 2009 14:34 UTC (Thu) by kilpatds (subscriber, #29339) [Link] It's not that hard to do: I've even got a library (PrivMan) to help. But it's still a good idea: it's usually a good idea to reduce the lines of code you have to audit/trust, and a good idea to replace less audited code with more audited code.
|
|||||||||||||