🚀 go-pugleaf

Submitted-by: gwyn@smoke.brl.mil (Doug Gwyn)

In article <15ibqsINNc3a@ftp.UU.NET> toon@moene.indiv.nluug.nl (Toon Moene) writes:
>Short question: Why is it considered a security risk when people give away  
>their own files (by chown'ing them to someone else) or setuid 'user' their  
>own executables (OK, they have to be careful here) ?

The cited excert from Cray did not state that there was a security risk
involved.  In fact, to the contrary it is worse security for a user who
needs to set the SETUID bit on an application to have to be given super-
user privilege than the way UNIX traditionally worked.

There would be a security issue if, having set the SETUID bit on an inode,
the user could then change the inode's associated user (owner), but all
UNIX implementations I know of anticipated this and clear the SETUID bit
upon a chown with non-zero EUID (i.e. the superuser can do this but nobody
else can); also of course the SETUID bit cannot be set (except by EUID 0)
on any inode whose associated user doesn't match the EUID of the chmodder.

The research branch of UNIX has long prohibited chown by non-zero EUID,
giving as rationale the notion that it would interfere with file quota
subsystems (which didn't exist anyway at the time).  The commercial flavor
of UNIX has long allowed users to chown their files to somebody else,
clearing the SETUID bit in the process, in order to reduce the number of
instances in which superuser permission would be required.

I can think of a couple of practical reasons why Cray and/or other POSIX
followers might want to change the traditional UNIX behavior.  One is
that some "layered" POSIX implementations don't have the requisite
underlying support for correct set-UID operation.  There may be
especially tough problems in getting this to work reliably on certain
brain-damaged Network File Systems.  Another probable contributor is the
move toward more secure UNIX-based environments, particularly those
meeting DoD requirements wherein Mandatory Access Controls must be
provided.  A lot of the original IEEE Std 1003.1 was phrased to allow
the success of certain operations to depend on "suitable privileges"
rather than on the traditional EUID 0, specifically to support alternate
(presumably more rigorous) access control mechanisms.  It is not clear
that such more rigorous security mechanisms could coexist (without loss
of security) with the traditional set-UID approach.

I must say that in theory, EUID 0 privilege combined with set-UID
execution suffices for rigorous security control; however, it forces
all implementation of security policy to be forced through some
"knothole" using that facility.  (There are numerous examples of this
in practice.  We used it for our huge MUVES project recently.)  Many
people feel that the security policy needs to be more transparent to
applications (i.e. handled by the kernel) than is possible with the
traditional approach.


Volume-Number: Volume 28, Number 72