LWN.net Logo

Advertisement

E-Commerce & credit card processing - the Open Source way!

Advertise here

Fixing CAP_SETPCAP

Fixing CAP_SETPCAP

Posted Nov 2, 2007 1:43 UTC (Fri) by dvdeug (subscriber, #10998)
Parent article: Fixing CAP_SETPCAP

I don't understand why the inheritance bits make things much safer. If login doesn't have a
capability, but its children do, a crack of login can just run a program with the needed
capability. It's an extra hoop to jump through, but I don't see where it adds much.


(Log in to post comments)

inherited capabilities

Posted Nov 2, 2007 22:52 UTC (Fri) by giraffedata (subscriber, #1954) [Link]

I don't understand why the inheritance bits make things much safer. If login doesn't have a capability, but its children do, a crack of login can just run a program with the needed capability. It's an extra hoop to jump through, but I don't see where it adds much.

That's if the crack is complete enough that it can run an arbitrary program. Cracks are often much weaker. For example, the program can be tricked into writing to an arbitrary file when it thinks it's writing to its log file because it uses an environment variable for the log file name. If the program has voluntarily given up its ability to override file permissions, this crack won't get very far. The program is able to spawn a child that can write to any file in the system, but this cracker isn't able to make it spawn one that will.

The other side of inherited capabilities is that you can make sure your child enjoys less privilege than you have.

But I don't know if any of this justifies an inheritable capability mask. You could do just as well by setting your effective capabilities just before exec and have those be the inherited capabilities.

Copyright © 2008, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds