* Bruno Wolff III <bruno@xxxxxxxx> [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
Attachment:
signature.asc
Description: Digital signature
-- fedora-selinux-list mailing list fedora-selinux-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-selinux-list
