The context dependent files, as they appear to be implemented in the
transname patch, looks like a source of security holes. Do not enable the
transname patch without limiting its effect to a single group (a
compile time option).
Many of the possible exploits involve creating files with
the for /targetfilepath#hostname=myhost# where myhost is the
local machine. In general, if you have access to a directory
you can tamper with almost any file in that directory, even
ones you do not own or have write or delete access to.
Instead of "host=myhost" you can also use "System=Linux",
"machine=i486", or "ktype=_____".
This is similar to the problem of symbolic links in /tmp but it has a
difference: The permissions of the original file do not matter, the
permissions of the substitute file matter. So while the ability to create
a file or symlink in a directory only matters when the file you wish to
tamper with does not already exist (or the program will later try to
create it and fail but not notice), this adds a whole new set of problems
relating to existing files.
Any program which writes a file in /tmp, closes it, and then
rereads it is vulnerable to a new set of race conditions which
were fixed by the original "t" bit symantics but probably broken again
by this patch.
Note that there is a a compile time switch to determine whether
/originalpath or /orginalpath#condition=true# takes precedence.
The default (the later) is assumed here; the alternate
configuration has the same security holes, just reversed.
The sensitivity of the translation to an environment variable
creates many posible exploits.
When the translation is enabled, it is even more important than
usual to protect the directories (as well as the files) in:
- /etc tree
- /usr tree and all other sources of executables
- /tmp and other shared directories
- User''s (priveledged and unpriveledged) home directories.
dot files are now vulnerable even if they exist and have
strict permissions.
As far as implementation, I also find kernel routines which return
strings by returning pointers to statically allocated characters
to be a BAD IDEA(tm). Are these patches only inside routines
which are gauranteed to be atomic? Are the functions only
called once during the scope of the return variables?
Will everyone who patches the kernel source remember this?
I have only looked briefly at the patch source and not in context.
Documentation is sparse concerning the actual semantics
of this behavior. No system call manual pages were updated.
This is not safe.
The implementation appears to be unnecessarily slow; I think it
probably could have been implemented without a significant performance
hit. A feature
that was intended to help performance (restricting translation
to directories with a certain group) may improve security
by preventing translation from affecting the entire filesystem.
But it may also place unwanted constraints on the permissions availible to
you. If you want setgid programs to be able to read from
a certain directory but not other programs, for example.
Even restricted to one group, the performance hit would affect
all files in the /etc tree (because that is where you
most want this functionality in the first place) some of
which are likely to be very important to overall system
performance.
Depending on the compilation options and the options specified
in the #condition=...#, more than one file of the same name
may exist.
By contrast, context sensitive symbolic links do not appear to have
any NEW security problems as long as the context is as immutable
as "hostname" and "domainname". If you start allowing the
context
to change per process or allow the parents context to be changed...
For the symlink, version, there could also be two versions
of $HOSTNAME with different names, which would affect:
- whether the name is translated by the host itself locally
(always true)
- whether the name is translated by the NFS server (for dumb
clients) (optional)
- whether the name is translated by the NFS client (always
happens if the server doesn''t get to it first).
This could be done using ${HOSTNAME:options}.
Some control could be given as to wether the non ${HOSTNAME}
portion gets evaluated on client or server without the "../../.."
traditional KLUDGE.
Context sensitive symbolic links might break some programs which
had security related code for dealing with symbolic links if
they read the actual text of the symbolic link instead of simply
testing if it was a link before traversing it.
---------------------------------------------------------------------------
--- Mark Whitis <whitis@dbd.com> WWW: http://www.dbd.com/~whitis/
---
--- 428-B Moseley Drive; Charlottesville, VA 22903 804-962-4268 ---
---------------------------------------------------------------------------
From mail@mail.redhat.com redhat.com (list@199.183.24.1)
