lkml.org 
[lkml]   [1998]   [Apr]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [patch 2.1.97] more capabilities support
Date
>> 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).

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

\
 
 \ /
  Last update: 2005-03-22 13:42    [W:0.297 / U:0.244 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site