[techtalk] partitioning security (was lilo)

Julie jockgrrl at austin.rr.com
Wed Jul 25 23:21:48 EST 2001


jenn at simegen.com wrote:
> 
> Andrew Wendt wrote:
> 
> > On July 25, 2001 03:23, coldfire wrote:
> >
> > What prevents the same thing from happening with a soft link?
> >
> 
> I don't know the terms 'hard link' and 'soft link', but with a
> symbolic link created with 'ln -s', the permissions of the
> source of the link wind up being the permissions of the target.
> I don't know if/how partitions affect things.
> 
> However, since it seems hard links can affect security, perhaps
> someone would like to tell me: what are they? How/why do they
> create such holes?

In the most abstract sense, a symbolic link is simply a name.
So if you have "/tmp/foo" and it's a symbolic link to "/root/private"
and /root has permissions 0700, you can only perform the operations
on "/tmp/foo" that you could perform if you replaced that name with
"/root/private".  If "/tmp/foo" is a hard link, the permissions on
"private" determine what rights you have.  So if "private" has
permissions 0666 you can write to the file if it is a hard link,
but not if it is a soft link (and you aren't root ...).

Where it becomes Really Interesting is where you can exploit race
conditions and/or sloppy coding.  Consider the case where a program
verifies accessibility in two steps -- first examining the access
rights to a file, then opening the file (very common where a
daemon is acting as privileged process on behalf of an unprivileged
user).  This is an exploitable race -- begin with a file which is
accessible to the unprivileged user, then after the daemon has
verified accessibility, switch the link to an unaccessible file.
This might sound hard to do, but it's actually very simple -- if
you know how to slow a process down enough such that you can "do"
things in between its system calls (think about nice() and the
addition of a few CPU bound processes to the job mix ...).
Several of my friends and I had perfected this back in the 80s
and were able to expoit all kinds of set-UID programs (like the
System V "mkdir" command ...).  Forbidding symbolic links makes
exploiting such holes harder -- as does the use of system calls
such as fchown() and fchmod().  Forcing hackers to use hard links
requires that they have a world-writable directory on the same
partition (and here is where partitions come into the picture) as
the desired file.  Thus "/" should NEVER have a world-writable
directory on it -- if there is an exploitable race files such as
/etc/passwd and /etc/shadow become easy targets.

ANYHOW, not sure if that's more or less info than you wanted ...
-- 
Julianne Frances Haugh             Life is either a daring adventure
jockgrrl at austin.rr.com                 or nothing at all.
					    -- Helen Keller




More information about the Techtalk mailing list