Access Control (was: Re: Real-time alarms) (fwd)

[Robert Watson]

On Thu, 30 Sep 1999, James Buster wrote:

> On Sep 30,  7:38pm, Robert Watson wrote:
> } POSIX.1e describes a set of capabilities + interface, which the Linux
> } people have already implemented (with extensions to make it useful).
> 
> Other than a set of administrative capabilities, what extensions have
> they added? We had to do the same for Irix, but the basic set of
> capabilities was otherwise quite sufficient.

Been a little while, I but I believe they created capabilities such as
"bind privileged port", etc.  A lot of UNIX-oriented privileges that are
fairly specific.

> } I am not convinced that the approach selected in POSIX.1e is the correct
> } approach--the lack of extensibility for capabilities looks pretty
> } limiting.
> 
> Once you've dealt with least-privilege for a while you being to realize
> that having a small, limited set of capabilities is the only way to go.

For a centrally-managed source base, yes, but given the presence of so
many loadable kernel modules, I was interested in the possibility of a
sort of string-oriented hierarchal namespace so that new modules could
have new capabilities associated with them.

> } It connects to /var/run/token (a unix domain socket) and transfers to
> } token to the socket, along with a request for authentication to the
> } username account.
> 
> So tokend does password lookup/decryption/management? How does
> authentication information change under this scheme?

I implemented a few token requests, allowing exchange for new tokens, and
also some key management requests to change password data maintained by
tokend.  Clear-text tokens were passed to tokend, where it could evaluate
the validity of the token for authorizing further behavior as it saw
fit--looking up in a password file, etc.

> } Tokend, based on a policy file, would allow the exchanges of specific
> } types of tokens for other tokens--for example, a valid username/password
> } token for a set of UNIX uid and gid tokens representing a traditional user
> } credential set.
> 
> What does a process *do* with these tokens? Pass them into the kernel?
> How does the kernel validate a token given it by a process? Are tokens
> inheritable by children?

Tokens, in my implementation, were managed by the kernel.  Each PAG
(Process Authentication Group) had a list of tokens associated with it.  I
provided token identifiers to the user process, similar to file
descriptors.  By default new processes are members of the same PAG as
their parents, but may call newpag() to leave their parent's PAG and
create a new one.  Tokens have a set of properties describing how the
kernel should handle this and other token-manipulation situations--there
is an inheritable bit, a transferable bit, an immutable bit, etc.
Privileged processes, such as tokend, may create tokens that have kernel
capabilities associated with them--these would be a good example of a
token to make immutable, and to limit the propagation of.  I have some of
the code and documentation online at

http://www.watson.org/fbsd-hardening/tokens/

A bit outdated, and not my latest code.  If I get a chance, I'll put my
newer more interesting code online sometime soon.  I believe the
proposal.txt file in that directory describes the basic theory.

Robert


  Robert N M Watson 

robert at fledge.watson.org              http://www.watson.org/~robert/
PGP key fingerprint: AF B5 5F FF A6 4A 79 37  ED 5F 55 E9 58 04 6A B1
TIS Labs at Network Associates, Safeport Network Services


To Unsubscribe: send mail to majordomo at cyrus.watson.org
with "unsubscribe posix1e" in the body of the message