[1280] in linux-security and linux-alert archive
Re: [linux-security] Re: t bit and symlinks patch
daemon@ATHENA.MIT.EDU (Joseph S. D. Yao)
Thu Oct 31 02:38:52 1996
Date: Tue, 29 Oct 1996 14:56:15 -0500
From: "Joseph S. D. Yao" <jsdy@cais.cais.com>
To: dholland@eecs.harvard.edu, R.E.Wolff@BitWizard.nl
Cc: linux-security@tarsier.cv.nrao.edu
> > Another way would be to make context sensitive symlinks. (Anybody
> > remember Domain-OS?). This would allow you to make /tmp a symlink to
> > $HOME/tmp . There are many more interesting uses of this feature...
> > Any volunteers? :-)
>
> This sounds a lot more interesting.
>
> What context do they reference, though? Reading environment variables
> out of user space sounds horrendous.
Domain-OS was a product of Apollo, which was bought by HP.
[REW: Correct, however I wasn't thinking about something like HPs
context dependent files. More along the lines of the old Apollo
variable symlinks. On the apollo you had /usr/bin in your path,
but that pointed either towards a sysV compatible set of binaries
or a BSD compatible set. However the special "process context" that
you mention is indeed what I was thinking about....]
HP-UX has a special "process context" string space. The process
context includes the system name; the various types of systems,
programs compiled for which will run on the current system; whether
the system is a diskful ("localroot") or diskless ("remoteroot")
system; and the string "default". The context can be read by
getcontext(2); there is no symmetrical setcontext(2) [as far as I can
tell]. Such a call must be implemented to make the above proposal
work.
The rough implementation of HP context dependent files (CDFs) is as
follows [from public documentation]. If a file is made context-
dependent, a "special" directory of the same name is created, and the
contents of the file itself are moved into a separate file for each
context name in /etc/clusterconf (typically, the names of all of the
hosts in a diskless "cluster"). Accesses to the file will access the
file whose name is the first "context string" found in the list. The
CDF directory itself can be seen by appending "+" to its name. (I
don't know what would happen if you had an "x" CDF directory and an
"x+" file or directory.) CDFs can be nested, to refine context
selection.
A CDF directory can be changed to a regular one via 'chmod -H x+', and
back via 'chmod +H x'. (Note the use of "+" in the first version.)
For instance, if I had a file /etc/rc and made it a CDF, I'd have a CDF
directory /etc/rc with the original contents of /etc/rc copied into
files named for my cluster hosts - call them joe, mary, teresa, and
chriss - plus "default". If I did an ls -l of /etc/rc+, I'd see the
five files; but if I did an ls -l of /etc/rc, I'd see whichever matched
my context (say, joe) as /etc/rc.
>From this, it seems to me fairly trivial to implement. For me, right
now, finding the time to do so is not. I won't be insulted if someone
else does it first. [;-)] However, I'm not entirely sure that this
will be the security panacea that seemed to be promised. I'm also
wondering whether it might open other security holes. Also, the HP
specific implementation was to allow file systems that were "context
shared", and would allow different configurations and executables when
run on different systems in the same shared "cluster". I don't believe
that NFS would allow this! and HP's networked file system and diskless
workstation boot protocol are (I believe) proprietary. I could be
wrong about either.
Joe Yao jsdy@cais.com - Joseph S. D. Yao
