jmcmullan@linuxcare.com
> Jesse Pollard <pollard@tomcat.admin.navo.hpc.mil> wrote:
> >> a) Have a centrialized, cross-filesystem way to inspect what
> >> capabilites are used (/etc/capabilties in conjuct with /etc/group)
>
> > Why is that any harder that /etc/cpabilities in conjunct with /etc/passwd?
> > I would prefer to keep the capability list with the inode for most things.
>
> The primary reason I like GID (or, based on your later arguments, a
> UID) based role system is that administration of capabilities is centralized.
> Just a personal preference, and it helps me with my old-fashioned
> ``what is user X up to'' as opposed to ``what is program X up to''
> system administrator mindset.
>
> > Nope. The problems:
> > 1. inadvertant granting of capabilities because a user gets added to a group.
> > 2. No positive identification and "least privilege" implementation. Just
> > because a GID is given a capability is no reason to give that capability
> > to all members of the group.
> > 3. Group access is a descretionary control. Capability lists are a mandatory
> > control. Don't mix the two.
>
> <ADVOCATE CLIENT="Devil">
> Excellent reasons why GID based role systems are bad. Let's go up
> a level - why not a UID based role system, then? A UID based system would,
> IMO, take care of problem (1) since capabilities are assigned to a single
> user, (2) since the UID gives positive ID and allows for ``least privilege'',
> and (3) it becomes a manditory control, if I understand that phrase
> properly.
> </ADVOCATE>
A UID based role system re-implements the all powerful root login. It does
however, allow moving that user to a non "root" name, but that can also be
done just by changing the login name of the root user. This does not
improve the current foundation, which is desired.
By least privilege - no user is all powerful.
To make the system usable, there must be a way to gain the necessary
privileges. To gain a particular privilege requires some way to authenticate
the user before granting the higher privilege. UID alone is not enough -
consider a cron job - should it have the same privileges as the user via an
interactive login where questions may be asked/answered? There are pros/cons
here that significantly affect the result. Both answers have been done -
Under UNICOS, my cron job cannot install privileged software; even though
I (via an interactive login) am. This is because the potential violation may
request additional authentication (ie. a password). If the cron job accepts
a password from the input stream, that means I have put a sensitive piece
of data (the password) in an unsecured location.
>
> > [snip discussion of working ``Trusted'' UNIX systems]
>
> >> Since POSIX tends to document standard practice - when standard
> >>practice leads to security, administrability, and maintainability -
> >>I think that - on this one issue - we should lead the way.
>
> > IMHO, that is partly why I think it was withdrawn. The timing of the
> > withdrawal appeared to be shortly before and during the debate over the new
> > "Common Criteria" (CC) for security specifications. The POSIX committe (I think)
> > decided to wait for acceptance of CC to become practice.
>
> Had CC become practice yet? What are some good examples that I
> can look at? (UNICOS? Trusted Solaris?)
>
> > [snip discussion of why a GID<->Capability role model doesn't work]
> >
> > 2. Another place that this causes problems is in NFS/NIS. There can only be 16
> > groups (NFS 2 limits, not sure on NFS3). An imported group identifier just
> > may grant privileges that are NOT to be given on the client system. Never
> > mind the problem of keeping track of which groups can/cannot be imported via
> > NIS.
>
> When did this 16 group limit on NFS/NIS come up? I've been using
> large-group NIS (over 60 groups!) for over two years, on Solaris and
> Linux, and NFS mounts, without any problems...
>
> > Out of all the systems, I like the Cray UNICOS administration as being
> > the easiest. Once the user database is defined (with capability lists)
> > then access control is very fine controled. In addition, there is the
> > PAL (privilage access list) that is assigned to inodes. These are used
> > similarly to setuid bits to grant additional security privileges based
> > on the PAL. Depending on the operating mode (PRIV-SU still has an all
> > powerful root - augmented by PAL+capability lists, PRIV-TFM is the B2
> > equivalent - no all powerful root, all security controls via capability
> > lists/PALs) the system can be made as secure as desired.
>
> The UNICOS UID<->Capability role system - that I like. Can it be
> implemented without the PAL on the inodes? Ie: (snipped from an offline
> discussion I'm having)
I think so. The PAL implementation is only used to extend the definition of
setuid - If the PAL definition doesn't allow setuid, then the program is
NOT setuid, even if the setuid bit is set. As far as I have been able to see,
this is the effect - more bits that work like the setuid bit does. Instead
of switching UID, it gains the privilege associated with the specified bit(s).
This allows extreme segmentation of privilege.
> My (so simple it's probably braindead) concept for UID-based roles:
>
> (for the purpose of the following, CAP_CAPUPDATE allows modification
> of the kernel capability<->UID mapping table, and CAP_SUIDOTHER
> allows marking inodes SUID if you don't own them)
>
> a) Use the capabilities as defined by the kernel
> b) Bind (via init(1)) capability masks to UIDs
> c) Only process id 1 has CAP_CAPUPDATE, which allows it
> to read /etc/capabilities and update the kernel
> with that information. (userful after adduser)
> d) By default, a file executed by a UID runs with
> a capability mask of 0
> e) The only time that capabilities are used is when
> an executable that is NOT writable by group or other
> AND marked SUID is executed. The executable then
> gets the capability mask of its owner's UID.
> f) Said process can then drop capabilities if needed.
> g) Said process cannot regain dropped capabilities,
> nor can if assign itself new ones.
> h) Only UIDs with CAP_SUIDOTHER (ie, ``classic'' root)
> can SUID an inode that doesn't belong to them.
>
> Seems to be dead-simple to me. You have a bunch of
> ``pseudo-users'' that own critical programs, ie:
>
> http httpd, apacectl, etc
> login login,xdm, etc
> console setleds,loadkeys, etc
>
> Everything else just stays the same.
This is re-implementing the "setuid to xyz" facility in a capability (as
assigned to a UID) system. I don't think it is as strong as a capability/inode
reference. No user can accidentially (even indirectly) gain a privlege that
is not explicitly assigned. This is NOT to say "privileges/capabilies" are
not assigned to a UID. It is not done explicitly. The assignment only says
"this uid is allowed to use the specified capabilities". The capabilities are
not allways on. The combination of inode capabilities must be matched against
the "allowed" capabilities. I realize this appears to contradict the inode
reference - I think this is where the "forced" capabilities come into play.
I think the "forced" capabilities permit totally unprivileged users to
accomplish something that does require privilege - such as changing a password.
It doesn't grant the ability to change just any password; only the password
of the user using the passwd utility, even then the user must provide the
old password. Changing any password requires additional capabilities/role
definition (such as security administrator - there may be several capabilities
used to define the role of security admin).
-------------------------------------------------------------------------
Jesse I Pollard, II
Email: pollard@navo.hpc.mil
Any opinions expressed are solely my own.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Tue Feb 29 2000 - 21:00:20 EST