BSD-style securelevel comes to Linux

BSD-style securelevel comes to Linux — again

Posted Sep 11, 2013 21:11 UTC (Wed) by geofft (subscriber, #59789)
In reply to: BSD-style securelevel comes to Linux — again by Cyberax
Parent article: BSD-style securelevel comes to Linux — again

I'm not sure I follow -- can you expand on what you mean by "the environment itself"?

Do you mean that the hardware/firmware platform is supposed to provide enumerated capabilities to the OS?

(Log in to post comments)

BSD-style securelevel comes to Linux — again

Posted Sep 11, 2013 21:17 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link]

No. A capability-based OS would simply not provide required caps to programs that don't need them.

Also, the capability-based security literature means quite a different thing by 'capabilities'. The actual example of capabilities in Linux are not security cap. bits, but file handles. A program can securely transfer them, use them and can't forge them.

BSD-style securelevel comes to Linux — again

Posted Sep 11, 2013 21:26 UTC (Wed) by geofft (subscriber, #59789) [Link]

Yeah, I'm using "capability" here in the research-literature sense, not in the Linux sense.

I think "don't provide capabilities to programs that don't need them" is so underspecified as to not be useful. Let's take the USB example -- say a process is the USB driver on some awesome microkernel architecture. Then USB 3 shows up, and something in the USB 3 spec means that several users want to be more careful about what can speak to USB 3 host controllers (maybe it interacts with power consumption), but several other users also don't care. Should the USB capability -- the ability to drive any USB 1 or 2 host controller on the system -- also grant access to a USB 3 host controller? "Yes" means that you've lost some of the security promise of a capability architecture; "no" means that the users who don't care complain about breaking userspace.

BSD-style securelevel comes to Linux — again

Posted Sep 11, 2013 22:51 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link]

Nope. USB3 controller would have its own capability, so only processes that need it would be able to get access to it.

If USB3 needs some special handling then this logic would be encapsulated in some kind of server process.

BSD-style securelevel comes to Linux — again

Posted Sep 11, 2013 23:01 UTC (Wed) by geofft (subscriber, #59789) [Link]

Yes, but now you took an OS where you could plug in a flashdrive and have it work, changed hardware, and now that no longer works without modifications to userspace. By making USB3 a separate capability, you've broken userspace.

(Or so goes the argument against adding a new Linux-style capability for Secure Boot.)

BSD-style securelevel comes to Linux — again

Posted Sep 11, 2013 23:13 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link]

Sure, but these modifications will be confined to policies. End-user programs won't have to be modified in any way.

BSD-style securelevel comes to Linux — again

Posted Sep 12, 2013 20:22 UTC (Thu) by zooko (subscriber, #2589) [Link]

Sigh. I wonder how much damage has been done by Linux using the word "capabilities" for their non-capabilities access control scheme?

"It seems that there is a fundamental flaw in the capability model: it is nearly impossible to add new capability bits without risking problems with applications that do not know about the new bits."

If you mean Linux's non-capabilities "capabilities", then yes! Your article succinctly explains the fundamental problem with them. If you mean real capabilities, then no! Real capability systems do not have this problem.

Blame POSIX not Linux

Posted Sep 12, 2013 22:26 UTC (Thu) by david.a.wheeler (subscriber, #72896) [Link]

The terminology problem is from POSIX, not Linux. There was a POSIX group ("POSIX Security Extensions") that defined a draft spec that used the term "capabilities" for something completely different than what many other people called capabilities. Linux implemented that draft POSIX spec, and thus uses its terminology.

BSD-style securelevel comes to Linux — again

Posted Sep 13, 2013 1:33 UTC (Fri) by giraffedata (subscriber, #1954) [Link]

I've always rejected the concept of a program dropping privileges, and I run systems in which untrusted programs never do that and instead receive an environment with only the capabilities they need. It's based on regular Linux kernel capabilities, though: the program capexec sets the privileges (capabilities, uid, gid) of a new process and then execs the untrusted program. Process 1 has all capabilities, but system configuration determines what lesser capabilities all the other processes have.

Whether a program chooses its own capabilities or some OS facility establishes them, it seems to me the issue of changing the capabilities in future kernel releases is the same. If you make a certain capability bit give less privilege in Release 2 than it did in Release 1, you'll have trouble. If you never do, you can't ever tighten security.

And sometimes, it's a matter of opinion whether a certain capability bit is more powerful in Release 2 because the set of things that are possible in the two releases is different.

BSD-style securelevel comes to Linux — again

Posted Sep 19, 2013 21:29 UTC (Thu) by mm7323 (guest, #87386) [Link]

I've always rejected the concept of a program dropping privileges, and I run systems in which untrusted programs never do that and instead receive an environment with only the capabilities they need.

Being able to drop caps can be useful to programs which may startup, perform some privileged actions, then drop the caps that aren't needed.

The simplest example would be a server process that wished to bind to a low port (<1024) using CAP_NET_BIND_SERVICE. Once the bind() is done, the capability can be dropped, but the already obtained file descriptor for the socket stands and can still be used.

There are other ways this could be done, but using libcap to drop capabilities at the right time is straight forward to implement.

BSD-style securelevel comes to Linux — again

Posted Sep 19, 2013 22:48 UTC (Thu) by hummassa (subscriber, #307) [Link]

Why not

chown nginx.nginx /dev/port/80

and then starting nginx as user nginx, group nginx? no privileges used, only at install-time...

BSD-style securelevel comes to Linux — again

Posted Sep 20, 2013 0:41 UTC (Fri) by dlang (✭ supporter ✭, #313) [Link]

because you would have to create the whole infrastructure for /dev/port/80 first. and if you can get agreement from everyone on how that would work, you will have done something very impressive.

BSD-style securelevel comes to Linux — again

Posted Sep 20, 2013 11:55 UTC (Fri) by cortana (subscriber, #24596) [Link]

Perhaps I'm naïve in hoping that systemd's tmpfiles.d mechanism can be adopted more widely.

echo c /dev/port/80 0700 nginx nginx - maj:min > /etc/tmpfiles.d/nginx.conf

BSD-style securelevel comes to Linux — again

Posted Sep 20, 2013 2:18 UTC (Fri) by mathstuf (subscriber, #69389) [Link]

Well, the cases I can think of that this scheme misses as-is are: what interface for port 80? TCP or UDP? Which IP addresses? Then how to persist that information (udev I assume). That's a lot of bikesheds.

BSD-style securelevel comes to Linux — again

Posted Sep 20, 2013 1:46 UTC (Fri) by giraffedata (subscriber, #1954) [Link]

The simplest example would be a server process that wished to bind to a low port (<1024) using CAP_NET_BIND_SERVICE. Once the bind() is done, the capability can be dropped, but the already obtained file descriptor for the socket stands and can still be used.

That's exactly what I object to and what I don't do on my system. Instead, a privileged program dedicated to binding sockets runs with CAP_NET_BIND_SERVICE and binds the socket, then execs the server program. The server program inherits the file descriptor, but no capabilities.

That way, I don't have to trust the server program to use CAP_NET_BIND_SERVICE properly, and drop it properly. I only have to trust the one binder program, which does the job for everyone and is very stable.

(And besides, I don't like having all that duplicate socket setup code in every server program - another good reason to have a separate program dedicated to that).