BSD-style securelevel comes to Linux

BSD-style securelevel comes to Linux — again

Posted Sep 13, 2013 3:41 UTC (Fri) by dlang (✭ supporter ✭, #313)
Parent article: BSD-style securelevel comes to Linux — again

Actually, what several of us (including HPA) in the thread were calling for was not for this to use the existing Linux capabilities (i.e. something tied to a running process, or filesystem point)

but instead to be using capabilities in the general sense, a bitmask that enables/disables things feature by feature for the entire system.

This doesn't suffer the major nightmare of the current per process capabilities system does.

It would also allow for a system to be locked down MORE than what Matthew is looking for, allowing the lockdown to be used by more people.

for example, you may want a lockdown capability that disabled ALL module loading after a specific point in the boot process

or one that completely disabled the ability to mount a device.

such lockdown capabilities would be very useful to have on a voting machine for example.

Yes, Matthew does have a point in that there is the possibility of someone adding a "do_evil()" syscall and a corresponding "prevent_do_evil" lockdown capability. In such a case, someone trying to run a locked down machine with a new kernel, but an old userspace would inadvertently allow the do_evil() call.

But if someone is really trying to run a locked down system, why would they be upgrading the kernel without upgrading the corresponding userspace? as long as triggering unknown lockdown capabilities doesn't cause an error, the new userspace will run just fine on the old kernel.

The idea that there is a one-size-fits-all definition of what a securelevel locked down system should consist of is just faulty. Different people with different use cases will want different amounts of lockdown. what's very reasonable for one person is completely wrong for another.

David Lang

(Log in to post comments)

BSD-style securelevel comes to Linux — again

Posted Sep 13, 2013 8:13 UTC (Fri) by ernest (subscriber, #2355) [Link]

>>But if someone is really trying to run a locked down system, why would they be upgrading the kernel without upgrading the corresponding userspace? as long as triggering unknown lockdown capabilities doesn't cause an error, the new userspace will run just fine on the old kernel.

There can be many good reasons for this of course: Upgrade of some hardware in the old but otherwise perfectly fine system? maybe something broke down but can only be replaced by something too new for the current kernel.

BSD-style securelevel comes to Linux — again

Posted Sep 13, 2013 8:56 UTC (Fri) by dlang (✭ supporter ✭, #313) [Link]

there are good reasons to upgrade the kernel, but are there good reasons to upgrade the kernel without being willing to upgrade anything else?

remember, this isn't the home user we are talking about here, this is someone who is trying to lock down the system in a way that even root can't change it.

anyone going to that much effort isn't going to be randomly upgrading one component.

BSD-style securelevel comes to Linux — again

Posted Sep 13, 2013 19:36 UTC (Fri) by khim (subscriber, #9252) [Link]

there are good reasons to upgrade the kernel, but are there good reasons to upgrade the kernel without being willing to upgrade anything else?

Depends on your definition of “anything”. Kernel is often upgraded if you need/want to support new hardware capabilities. Sometimes you then need to upgrade some low-level components (things like modproble), but you don't expect to change the setup of the whole system just because you've installed new CPU and want to use AVX512 in your programs.

BSD-style securelevel comes to Linux — again

Posted Sep 14, 2013 1:26 UTC (Sat) by dlang (✭ supporter ✭, #313) [Link]

remember that we are not talking about POSIX capabilities that your programs all need to know about.

We are talking about features that you can turn off to lock your machine down (protecting it even from root)

I would expect that there will be one program to do this, and it will probably be executed exactly once per boot cycle. (unless it's a developers machine)

So saying that if you upgrade the kernel and are trying to lock down the machine, you need to check for new lockdown flags that may have been introduced and decide if you want them doesn't seem at all unreasonable to me. In fact, it sounds like what would happen anyway with anyone competent dong a kernel upgrade, you would check new kernel compile options to see if something new pops up that may be a problem.

Look at the namespace features for a perfect example.