[techtalk] partitioning security (was lilo)

Almut Behrens almut_behrens at yahoo.com
Thu Jul 26 11:18:59 EST 2001


On Wed, Jul 25, 2001 at 11:21:48PM -0500, Julie wrote:
>
> 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 ...).

sorry for being picky, but I don't think that the latter statement
about the hardlink is technically correct. The 'problem' is, that
file permissions, ownership, timestamps, etc. are stored in the inode,
not together with the filename entry in the directory. And each file
has exactly one inode, so there simply cannot be different permissions
for the same file, independently of whether it's accessed via hardlink
or symlink.

As Andrew has nicely explained, a file can have multiple names, all
pointing to the same inode number. The filenames are just entries in
the directory which associate the name with an inode number. When
several filenames point to the same inode, we call them hardlinks.
(The way 'ls' displays the information can be somewhat misleading, in
that it puts filenames, ownership and permissions next to each other,
leaving out the intermediate internal derefencing step via the inode
number.)
BTW, after having created several hardlinks to a file, it is impossible
to tell apart which of those represented the file 'originally', in the
sense of having been created first -- even the timestamps are the same,
because they are stored in the inode.

Whether you can create a symlink to a file does not depend on the file
itself (permsissions, ownership, groups), but on whether you can read
any of the directory entries that point to it.
As an example: you can easily create a link to the file /etc/shadow as
an ordinary user, though the file itself is typically only accessible
as root. The thing is here that you can read the directory /etc and
thus determine the file's inode number, which is all you need to link
to it. But having created that link doesn't mean that you could read
the file's contents -- you've just added another reference to it.

While we're at it, it might be worth pointing out another source of
confusion often seen with unix newcomers.  It has to do with the
link/unlink(rm) commands operating on the *directory entries*, not the
files themselves. This means that you may be able to remove a file
even if its not owned by yourself and you can't read it. All that is
required is that you have write access to all of the directories that
contain a filename pointing to it (in practice, this is often just one
directory). Once you've removed the last filename/reference to the
file, its reference count drops to zero and the OS deletes the file
(when there are no longer any processes using it), as it would no
longer be accessible.  Put differently, this means that just by making
a file owned by root with permissions 400 or 600, you cannot stop
someone malicious from deleting the file, as long as [s]he has write
access to the directory containing the (only) filename referencing it.

Reversing this logic, there can of course also be files owned by
yourself and writable by yourself, which you still cannot remove.
This would happen if (one of) its associated filename(s) happens to be
an entry of a directory you cannot write in...
(you can truncate them to zero length of course to delete the file's
contents, but you can't remove the file completely in this case)

[just for a moment, think about what this means for files containing
sensitive data: if you 'just delete' the file, it might still be there,
if someone else had created a hardlink to the file before you deleted
it... So, if you want to be sure to *erase the content*, look at the
reference count first or better simply truncate the file to zero length
*before* deleting your reference/filename to it -- once you removed
your handle to it, you can no longer tell where it's still being
referenced from, and as you no longer have access to it, you can't
erase its content any more...]

BTW, another thing that occasionally strikes people is related to
creating hardlinks in /tmp to files not owned by yourself. This has
to do with the sticky bit typically being set on the /tmp directory,
which means that directory entries can only be removed by the owner
of the file that the entry references.  For example, any user could
make a hardlink to the file /etc/shadow in /tmp (if both reside on
the same filesystem), but [s]he wouldn't be able to remove the link
again, because the file behind it is owned by root.


A final note on security: both hardlinks and symlinks are not insecure
'by themselves' in any way. It's *always* some badly written programs /
daemons running as root (or some other UID you need to do harm) which
make exploits feasible.  More on that (and secure ways to have daemons
create temp files in /tmp ) upon request -- I think I've already again
used up my allotted 5 kByte/day ;)

- Almut





More information about the Techtalk mailing list