autorelabel and sym links

[Thomas Bleher]

* Bruno Wolff III <bruno at wolff.to> [2006-03-18 19:48]:
> When a file system is relabelled, how are files pointed to by sym links
> affected? I can think of several different ways they may be handled, but
> I haven't found any clear cut documentation on this subject.

Symlinks have security contexts like any other filesystem object.
The relabel process doesn't look at the file the symlinks points to but
just relabels the link according to the place it lives in the
filesystem.
If you look at the file_contexts file you'll notice that it is also
possible to set the context depending on filesystem object type.
Eg the line
> /vmlinuz.*         -l      gen_context(system_u:object_r:boot_t,s0)

will result in everything starting with /vmlinuz being labeled as
system_u:object_r:boot_t, but only if it is a symlink (see the -l). The
possible values are:
  -- regular file
  -d directory
  -s socket file
  -p named pipe
  -c char device file
  -b block device file

> Similarly how does restorecon -R behave? Currently the man page is silent,
> but a google search turned up a change log entry suggesting it doesn't
> follow sym links.

That's true. restorecon doesn't need (and isn't allowed to by policy) to
read where symlinks point to. This is very helpful in preventing symlink
attacks.
Hardlinks are more problematic. Setfiles (which runs when the whole
filesystem is relabeled) keeps track of hardlinks and warns if a file
would get two different security contexts because of its different file
names. I don't know if restorecon has a similar check but it cannot
reliably detect this problem if it's only run on part of a filesystem.
This is the reason you should (on targeted policy) never run restorecon
on untrusted userdata.

Thomas
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://listman.redhat.com/archives/fedora-selinux-list/attachments/20060319/62631cfd/attachment.sig>