Re: [patch 2.1.97] more capabilities support

Alexander Kjeldaas (astor@guardian.no)
Mon, 20 Apr 1998 22:52:27 +0200


On Mon, Apr 20, 1998 at 03:24:49PM +0100, Chris Evans wrote:
>
> Ok, when I said "nobody", I probably should have quoted users like
> "fingerd", "httpd", "authd" -- you can guess what sort of programs these
> execute on our machine! They never need any privs and I would like to feel
> confident neither they nor their children can get any, in case a bug
> allows a remote shell to be spawned as one of these users.
>

You can ensure this by doing the following:

1) Don't store executables on the system with forced bits (this
requirement is automatically fulfilled in the current implementation
since we don't have file system support).

2) Don't run any "capability-daemon" with the CAP_SYS_SETPCAP
capability (or other capabilities like CAP_SYS_ADMIN that I assume can
be hacked to promote other capabilities).

> 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.

> 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].

> Are people more enthusiastic about a bounding set now? ;-) It is surely
> worth it for the truly minimal amount of code needed to implement it. I'll
> do it if need be.

No :-) I haven't seen a good argument for it yet. It is trivial to
implement, but it carries a conceptual burden and thus more users will
be confused and in the end it hurts security.

IMO, it is a system security policy whether you want to use forced
bits or allowed bits to give capabilities to processes. If you need a
'bounding set' the natural choice for your system is to use the
allowed set to give processes capabilities. On that system, the
inheritable bitmask will work exactly like the bounding set.

astor

-- 
 Alexander Kjeldaas, Guardian Networks AS, Trondheim, Norway
 http://www.guardian.no/

- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu