2

I noticed that the rule

/usr/sbin/shutdown  --  gen_context(system_u:object_r:shutdown_exec_t,s0)

labels /usr/sbin/shutdown shutdown_exec_t when /usr/sbin is a directory. But it doesn't restore the same label when /usr/sbin is a symbolic link to bin and shutdown is in /usr/bin. Why? If /usr/sbin is a symbolic link to bin, is there an easy way to give the files that are supposed to be in /usr/sbin the correct contexts?

It looks like that if an inode has 2 hard links to it, and the paths have different default file contexts, the resulting file context will differ depending on which path is given to restorecon. What context will it have if I relabel the whole filesystem? Is it deterministic? Is it ok or good to do so?

3

restorecon doesn't handle symbolic links just the way it handles files. According to the manual page (a little old, so useful as a starting point):

Note
restorecon does not follow symbolic links.

This was observed in a bug report, Bug 825221: restorecon disregards custom rules for sym links, with these pertinent comments:

  • Daniel Walsh 2012-05-29 13:54:13 EDT

    We just fixed this in F17.

  • Daniel Walsh 2012-08-15 14:01:52 EDT

    restorecon is doing a realpath on the file, so it is translating the file via realpath. We are doing this so that a symbolic link attack will not cause the file to get mislabeled.

  • Karel Srot 2012-08-23 06:14:05 EDT

    Just tested this on RHEL6.3 and Fedora 17.

    On RHEL6 restorecon doesn't restore the context of the symlink (when symlink is the actual item). On Fedora 17 the context is restored. I belive this is the problem mentioned in #c6.

    Dan, could you please confirm that this is what's is going to be fixed? Thank you.

  • Miroslav Grepl 2012-08-23 09:59:41 EDT

    Ok, we discovered bug in the policy. We do not have the following rule on RHEL6

    allow setfiles_t file_type : lnk_file { read getattr relabelfrom relabelto } ;

    We have just

    allow setfiles_t file_type : lnk_file { getattr relabelfrom relabelto } ;

    So I am switching this bug to selinux-policy component.

Somewhat later (2015), in Some questions about using restorecon on symlink , Stephen Smalley commented

Yes, they resolve to different inodes (a symbolic link is its own file/inode in Linux, separate and independent of the target). The symbolic link SELinux label only controls access to the symlink (i.e. the ability to unlink, rename, or read it), not access to its target (which is controlled based on the target's label).

So... barring some further rule, the symbolic links are (mostly) irrelevant to the permissions on the target that you're concerned about.

  • 1
    Is there an easy way to give the files that are supposed to be in /usr/sbin the correct contexts if /usr/sbin is a symbolic link to bin? – v7d8dpo4 Aug 15 '16 at 5:19

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.