Nice, but let's assume there are several buggy executables
with privilege all over the system. This is often true!
You could hunt down each one and apply ACLs (which we don't have)
or you could just prevent untrustworthy users from running them.
Blocking access to _all_ privileged executables is coarse-grained.
It would be nice to block only the executables which have the most
dangerous capabilities.
We can certainly live without this, just like we do now.
It is a "nice to have" type of issue.
>> The bounding set should not require any extra storage in the binary;
>> it is merely a "per-process" thing, and is esentially a mask.
>> It is directly copied upon fork, and exec. A process is allowed to
>> drop bits from this mask, but nothing can raise bits.
>
> OK, but I guess the bounding set would have the same
> restrictions/problems as the inheritable set wrt clearing bits to
> guard against the 'capability mismatch' problem.
Yes. It is easiest to just prevent execution totally.
>> At boot, process 1, init, could default to a mask of ~0, but the
>> entire securelevel concept can be implemented beautifully by
>> starting init with a mask with some bits set to 0. This would
>> presumably either be a boot line parameter, or a compile time
>> option for super-security.
>
> This doesn't emulate securelevel. To emulate securelevel you have to
> be able to set the bounding set of _all_ processes on the system at
> any instant in time. This requires a system call which iterates
> through all processes. Securelevel is typically used to gradually
> remove system calls or operations as the system boots. [For instance,
> we bind the securelevel to runlevel*1000 on our current distribution
> and we boot by going from runlevel 2->3->4->5].
OK. Adjustments to /proc/sys/kernel/securebits iterate over all
the processes.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu