> > On Sun, 19 Apr 1998, Albert D. Cahalan wrote:
> > > * a Bounding Set that serves as a fail-safe mechanism to ensure users
> > > cannot acquire more privilege beyond what they have been authorized
>
> The capability model is designed to change this. The recommended
> behavior for an executable on a fully capability-aware system is to
> not raise "effective" capabilities on startup. Since, without them, it
> has no immediate power. In order to become powerful, it needs to
> request that one or more of its permitted capabilities be made
> effective, with a system call.
This is largely irrelevant, sadly. A buffer overrun on the command line
still, like in the SUID case, gets the attacker complete control of the
program. The difference is the exploit code now has to call the
raise_capability system call before doing its nasty stuff. Of course,
_unlike_ the SUID case, an attacker will have a much more limited set of
privs to play with, so capabilities are an excellent damage limitation
scheme :)
> Chris Evans writes:
> > I perceieve the main benefit of this for users like "nobody"; with an
> > empty bounding set the user really can be "unprivileged", in the sense
> > they can't try and exploit your SUID/privileged programs to gain a root
> > shell etc.
>
> The point you raise here about "nobody" getting some power, is an over
> generalization.. In some rare cases (contexts), it may be appropriate
> for the "nobody" user to exercise a capability. In these cases it is
> the "authentication" component of the application that needs to make
> this decision and because of the context, this is generally not
> something that can be reduced to a couple of bits in the file's
> attributes.
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.
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.
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.
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.
Cheers
Chris
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu