[1278] in linux-security and linux-alert archive
Re: [linux-security] Re: t bit and symli
daemon@ATHENA.MIT.EDU (Miller, Raul D.)
Wed Oct 30 13:05:35 1996
From: "Miller, Raul D." <RDMiller@legislate.com>
To: linux-security@tarsier.cv.nrao.edu
Date: Mon, 28 Oct 96 12:44:00 PST
Wietse Venema (Oct 24):
> To keep semantics simple, I suggest the principle of least surprise:
> 1) don't allow the creation of hard links that the process can't
> remove, and 2) don't follow symlinks that the process doesn't own.
>
> 1) can be overruled when the process has superuser privilege; 2) can be
> overruled when the symlink is owned by the superuser or when the
> symlink is owned by the owner of its (source) directory.
(A) As has been mentioned before, if any of this done, it has to be
configurable -- it's non-standard, and might break existing code.
(B) As has been mentioned before, the semantics of rename prevent (1) from
being useful. Making rename non-atomic would break the reliability of code
which relies on this being an atomic operation. Because of this complexity,
I don't think (1) is on the right track.
(C) Rule (2) is overly restrictive, but is close to a good idea.
The right thing to do is probably the rule of least privilege -- when
following symlinks, drop any user privileges so that they do not exceed the
access privileges of the owner (and group) of the intervening symlink(s).
This might be non-standard, but it "feels right" to me. [Of course, this
would not effect either the real or effective id for the case of suid or sgid
programs -- though, conceivably, it might prevent them from being run.]
--
Raul
