LWN: Comments on "Restricting the network"

Restricting the network

hppnq — Mon, 18 Jan 2010 07:26:16 +0000

Most or all references to setuid in the article are to the permission bit, not the function call. The parentheses are a bit unfortunate.

That said, the setuid bit and the setuid() function are quite intimately connected: setuid() allows a program to drop privileges that might be elevated by means of a setuid bit. Either one does not make much sense without the other.

The main reasons why one should consider not using the setuid/setuid() mechanism are that it is not widely understood and not very portable. See, for instance, this paper (PDF).

Restricting the network

kleptog — Mon, 18 Jan 2010 06:09:29 +0000

I've never quite understood the use-case for restricting setuid(). Non-root users can't use it anyway and for root users its use is to *reduce* your privileges, so why would you ever want to forbid it?

What use I can see is preventing the setuid bit on executables taking effect, but that has nothing to do with the setuid() call.

Restricting the network

Kissaki — Wed, 13 Jan 2010 05:54:24 +0000

First, let me say that as a sysadmin, I think being able to restrict less trusted software's access to the network (or / and setuid programs) would be a great boon.

But (and this is a very big but), we need provable security. What we have with this feature, chroot, setuid, virtualization, etc. is the computing equivalent of security theatre. Don't get me wrong, it is pretty good security theater... these changes set "bad guys" back months, maybe years until someone learns how to escape the most recent jail or virtual machine.

We more people to learn about and push for true capability systems that fundamentally tie permission to manipulate an object with the object itself. The projects I was cheering for (most recently CoyotOS) have fallen by the wayside, while the we all suffer from ACL systems security flaws.

As a side benefit, capability systems would tend to reduce the 'unintended consequences' issue.

Note: I'm speaking about the capabilities described here: http://en.wikipedia.org/wiki/Capability-based_security and not the kernel capabilities system currently in place.

Pro LSM stacking

eparis123 — Thu, 07 Jan 2010 18:40:00 +0000

The topic of stacking has been mentioned a lot in the linux-security list in the last two years.

Schaufler has been calling for it for a long time, but I remember some core people (Al viro) mentioning possible performance problems due to the increasing number of pointer dereferences in the kernel hot paths.

Ofcourse no one offered an implementation yet so that benchmarks can be done, but it seems we're getting closer to this point.

Pro LSM stacking

dwheeler — Thu, 07 Jan 2010 15:40:54 +0000

I believe LSM stacking *should* be added. Yes, it can be abused, but anything can be abused. It would let people create small special-case LSM modules that could be combined with "big" modules like SELinux.

Restricting the network

eparis123 — Thu, 07 Jan 2010 03:32:29 +0000

This was a great write-up Jake. Thanks a lot.