[1261] in linux-security and linux-alert archive
Re: [linux-security] Re: t bit and symlinks patch
daemon@ATHENA.MIT.EDU (Wietse Venema)
Thu Oct 24 20:07:27 1996
From: wietse@wzv.win.tue.nl (Wietse Venema)
To: tridge@arvidsjaur.anu.edu.au (Andrew Tridgell)
Date: Tue, 22 Oct 96 10:30:24 MET DST
Cc: linux-security@tarsier.cv.nrao.edu
In-Reply-To: <96Oct22.090144+1000est.65092-27084+2569@arvidsjaur.anu.edu.au>; from "Andrew Tridgell" at Oct 22, 96 9:01 am
Wietse wrote:
> Hard links, soft links, either is sufficient to attack sensitive files
> by exploiting naive programs, but the `t' bit is not a requirement at
Andrew Tridgell wrote:
[Using the `t' bit as a way of requesting less insecure behavior]
OK, "do what I mean" semantics can make sense (this is like mounting a
file system `nosuid' in order to also disable device special files).
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.
I'll resist the temptation to propose changes to the semantics of
following symlinks in general. :-)
Wietse
