Advertisement
GStreamer Conference 2013, 22-23 Oct, Edinburgh
GStreamer, Embedded Linux, Android, VoD, Smooth Streaming, DRM, RTSP, HEVC, PulseAudio, OpenGL. Register now to attend.
| |||||||||||||
BSD-style securelevel comes to Linux — againBSD-style securelevel comes to Linux — againPosted Sep 13, 2013 1:33 UTC (Fri) by giraffedata (subscriber, #1954)In reply to: BSD-style securelevel comes to Linux — again by Cyberax Parent article: BSD-style securelevel comes to Linux — again 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.
(Log in to post comments)
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 notchown nginx.nginx /dev/port/80and 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.
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).
|
|||||||||||||