> Ok. I think I have a really hard head. Could someone please
>explain to me the rationale behind the ``POSIX semantics'' that
>have been bantered around in this thread?
Most of it has been/was specified in the rainbow series of security
docuemtnation produced by the US DoD.
> Every time I re-read the capabilities POSIX docs I (aside from
>getting a splitting headache) think that putting capabilities on
>INODES as opposed to GIDs is braindead. I mean, really really
>braindead.
>
> The POSIX model leads to the modification of all of our file
>systems, a lot of the user space utilities, and a BIG change in
>how system administrators perform system inspection. We've already
>hashed in the list the issues with find(1),tar(1),cpio(1) and other
>utilities, but I think that's just the tip of the iceberg.
System administration isn't the biggest change. Administration usually
means handling the status quo, applying patches to keep the status quo.
Kernel/System development - writing security aware applications that will
be given special privileges - is very difficult and needs a lot of supporting
documentation. I've tried it under UNICOS - the kernel is very secure...ges - is very difficult and needs a lot of supporting
documentation.ges - is very difficult and needs a lot of supporting
documentation.
Actually - only cpio is a target of issue, since it was designed to be
used for system backups. tar is classed as "user file backup" and hence
the output should only have the level of the tar process. It shouldn't
be able to read files above its level. Restore will label the files at
the level of the tar process extracting the files. (downgrading not possible).
Most of the reliable system level backups use the equivalent of dump. Dump
bypasses the file system to read the Inode list directly. This makes dump
an easier target to include the ability to backup inode security information.
The effect on find is only that find is a common point of searching for
files. Even there, it is not guaranteed that find can search ACLs or
capability files (it doesn't on Cray UNICOS).
>
> However, the capabilties-per-GID model seems (IMHO) to have a
>lot going for it. If GIDs have default capability sets (and assuming
>a GID for each major service a la ``http'',``man'',``ftp'',etc) then
>you:
>
> 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.
> b) Don't have to modify tar/find/cpio/etc when you move to a
> secure system.
>
> c) System administrators can keep all their ``known to work in
> the field'' knowledge about tracking SUID binaries.
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.
>
> I know that specs are ESSENTIAL to the Open Source project, and
>I've been around since '92 on Linux, and I remember the big was over
>BSD vs SYSV vs POSIX semantics back then. I also remember the extremly
>prudent choice to go with POSIX. That was a positive turning point in
>Linux development, and I applaud the POSIX standards committies for
>(mostly) turning out extremly effective specifications.
>
> However, I believe that POSIX DRAFT specs 1003.1e and 1003.2c
>were withdrawn for good reason - they are unworkable in real life.
They are difficult to follow, but they are based on expierience in trusted
system administration. They work to prevent accidental security exposures,
prevent security "leaks" of more privileged/sensitive data to less security
processes. Systems are used every day that support most (all?) of the
specs in that document. See the growing proliferation of "Trusted XX" operating
systems. All of these are implementing either most of or a superset of the
specifications containd in the "withdrawn" standard.
> 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.
> Now, I'm all ready for the flames. Although, I would find it a
>more convincing argument if you can tell me how the GID<->capabilities
>model is less (1)secure, (2)administrable, (3)maintainable than the
>POSIX DRAFT model, as opposed to simply pronouncing the work of the POSIX
>committee - even withdrawn drafts - as the work of $DIETY.
1. principal of least privilege - Just because a UID is a member of a group
does not mean that UID should get the capabilities of that group.
Consider what could happen (over time) if a UID becomes a member of multiple
groups - does that mean that the capability list of that UID should be
the union of all capability lists?
I would consider giving a project leader a given capability, but
not give other members of the project that capability. Some of them may be
trainees, where the project leader is more fully trusted.
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.
3. Depends on the definition of "maintainable" - Kernel source maintenance,
user administration maintainence, or filesystem maintenance. User
administration is already hard enough (I have to deal with 5 Cray UNICOS
systems with MLS, 3 Sun E1000's, 1 Origin 2000, a visualization lab with
an Onyx, Onyx2, and 15 or so SGI workstations).
Fortunately, mounting filesystems readonly (application servers), or
nosetuid/nosetgid covers most of the common file system maintenance.
We have dedicated administrators for the various hardware platforms.
If this is extended to the Linux community - the visualization lab will be
using the new SGI PC platforms (with Linux thank $DIETY), I will be doing
them too.
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.
BTW, the cray installation manager (and the distribution) maintain a
list of files that are to be assigned with extra privilege. These are
nominally (but not exclusively): login, passwd, telnetd, rshd, sshd, ftpd
(the last four are kerberized too), and a few less familar ones - tape
handling daemon, file migration daemon ... Anybody notice an exception ?
Sendmail is not privleged - It is started with a security classification
based on the classification of the network socket; no need for special
privilegs other than change UID. When started by a MUA it recieves only
the label of the user. There is a different spool directory for each
supported security level, automatically selected by a multi-level directory
(MLD) which is actually a symbolic link using the process security level in
the name. The special handling occurs whenever a pathname crosses a MLD
(which is a directory with the MLD bit set in the inode). If /var/spool/mqueue
is a MLD, then there exists /var/spool/.mqueue.<level> which is pointed
to by a virtual symbolic link /var/spool/mqueue. (I think I have the
description right.)
-------------------------------------------------------------------------
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:12 EST