lkml.org 
[lkml]   [1998]   [Mar]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Securelevel bitmap patch

On Sun, 29 Mar 1998, Linus Torvalds wrote:

> Even more importanly, you can _add_ capabilities. You might well want to
> have a "secure capability server", which would be the only process in the
> system that has the right to _grant_ privileges to others (ie or in new
> bits). Kerberos-like "tickets" (well, not really kerberos-like, but you
> get the idea).

ftp://ftp.kernel.org
/pub/linux/libs/security/linux-privs/doc/linux-privs.html/linux-privs-3.html

No "capability server" is needed. Capabilities a process desires are
stored on the filesystem itself, as the URL explains. It's very nice,
I've had a capability aware 2.0.3x running, and it's cool to have a
non-suid ping that works through a RAW_SOCKET capability! This of course
is wonderful for Linux security because (in this silly example) a new
security hole in ping means an attacker only gets to open raw sockets
instead of root :)

Only one (fairly big tho) shortcoming remains with the system outlined on
the above URL:

We need processes to have an "allowed" bitmap, (pA). If a privilege bit is
not set in a processes' "allowed" bitmap, that process nor any of its
children, may ever posess that capability, even if a binary executed
explicitly has this priv. in its permitted set (fP).

This way, the process' "permitted" set becomes

pP' = (fP | (pI & fI)) & pA (see the URL for what it was before)

This way, we can implement securelevel by making init drop required bits
from pA at boot -- then we are sure no process will ever be able to hit
I/O ports, hit the raw disk, or whatever.

It also has the pleasant side effect that if you have a user on your
system you don't trust as far as you could throw him/her, you can have a
pam_some_random_module that drops permanently all privs for that user,
meaning they won't be able to try and exploit any security holes in your
privileged binaries :)

Linus: "securelevel" as is, is completely useless. If you deem that we're
never going to have a BSD-like securelevel, please remove it immediately.
It is a shame that the securelevel patch you received would have secured
up 2.2 nicely, but this "linux-privs" project stuff is probably too big a
change for you to consider for 2.2.

Chris


-
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.091 / U:2.148 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site