Re: Securelevel bitmap patch

Alexander Kjeldaas (astor@guardian.no)
Mon, 30 Mar 1998 16:05:16 +0200

On Mon, Mar 30, 1998 at 10:04:21AM +0100, Chris Evans wrote:
>
> 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 :)
>

This has been mentioned before and it's trivial to implement. However,
I don't think it's needed, at least not for the reason you mention.

The situation you mention is already handled by capabilities.

The names of the different capabilities assigned to a file is somewhat
misleading in the linux-privs patch. A process has the
inherited/permitted/effective capabilities. For a file, the
'inherited' should be renamed to the 'allowed' set, the permitted the
'forced' set and the effective is a single bit saying whether the
executable should start with capabilities raised or lowered
(capability 'smart'/'dumb'). The POSIX draft doesn't talk about an
'inherited' or 'permitted' set for files.

The following equations are used:

pI' = pI
pP' = fP | (fI & pI)
pE' = pP' & fE [NB. fE is 0 or ~0]

Now, if we rename as I said, the equations make sense.

Now, a user on the system has a set of "inherited" capabilities which
indicates the *maximum* privileges he is allowed to obtain. This is
*exluding* the rare cases where you force a program (it's "suid"). The
point being that you don't *use* suid programs/the "permitted" set on
the filesystem on a privs system. You use the *allowed* set on each
executable and it is filtered by the inherited set.

This means that an "allowed" bitmap you mention would only restrict
the ability to set programs "suid" which is an exception in the first
place.

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