Fixing CAP_SETPCAP

Fixing CAP_SETPCAP

Posted Nov 2, 2007 23:33 UTC (Fri) by giraffedata (subscriber, #1954)
In reply to: Fixing CAP_SETPCAP by zooko
Parent article: Fixing CAP_SETPCAP

Is this the same kind of problem that these security modules I keep reading about are trying to solve?

I think it is, but a similar problem is equally important: you're running code which is essentially trusted (maybe you wrote it yourself), but you know it might be broken. While this program isn't supposed to erase log files, a cracker might exploit a bug and make it try. So you'd like a safety net, immune to any bug that might exist in that program.

In classic Unix, you'd have a problem establishing that safety net if the program must be able to scan all the files on the system, because the same privilege that lets you read all the files (superuser) also lets you write to them.

The Linux privilege classes ("capabilities") don't seem well chosen, though. 6-10 of them (depending on other system properties) are equivalent to all the rest -- i.e. having one allows you to get the rest. And most of the privileges you'd like to separate are piled into one: CAP_SYS_ADMIN.

---

(Log in to post comments)

The general use of CAP_SYS_ADMIN all around the kernel is what makes me doubt of any new
capability system extensions to what exists now.

I'm no security expert, but can't understand how they can overcame that without a major
overhaul all around the kernel code.

I see this new features as nice things to help secure a system, but this all seem just more
"hacks" around the fact there isn't any "grand scheme" for security well thought (I mean, in a
modern way, because we all know traditional UNIX security way is just obsolete).