Jesse Pollard <firstname.lastname@example.org> 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.
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
> [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
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)
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.
-- Jason McMullan, Senior Linux Consultant, Linuxcare, Inc. 412.422.8077 tel, 415.701.0792 fax email@example.com, http://www.linuxcare.com/ Linuxcare. Support for the revolution.
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to firstname.lastname@example.org Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Tue Feb 29 2000 - 21:00:13 EST