First of all, I do apologize if you felt my message uncomfortable and not respectful for any reason. Believe me. I just didn’t mean it at all. Maybe I might have chosen the wrong place for my posting. Anyway, my points were:

Yes, path name can be varied (therefore path names should be taken care)
Yes, inode for given object is unaffected (unchanged) and it’s one of the advantages of the label based security.
No, the example shown above does not prove the path name MAC’s fatal shortage

You kindly took your time to attend TOMOYO Linux BoF at OLS2007 (I really appreciated that and your advice that’s why I’m reading your Blog), so I assume you know how I evaluate SELinux and label based MAC. I never say path based MAC is better or more reliable, but I think path based MAC can be used for some place as an “option” or supplemental tool.

Again, I apologize for my previous posting.

This example has nothing to do with path based access control mechanisms or TOMOYO, it has to do with how hardlinks work on unix systems and how DAC permissions are attached to the inode. Please be a little more respectful and try to understand the post in the future.

I’m afraid but your example is too simple minded and not realistic.

How come you can expect “# ln /etc/shadow /tmp/shadow” succeed?
Have you ever tried that with path-based MAC?

It will fail unless you explicitly grant it in the policy definition at least
with TOMOYO Linux.

the UNIX permissions absolutely do not have anything to do with paths, only with inodes

As much as I agree that inode-based security is the way to go, there are times when your staement isn’t true. For example :


#mkdir d1 d2
#echo hello > d1/f1
#ln d1/f1 d2/f2
#ls -i d*/
d1/:
1479281 f1

d2/:
1479281 f2
#chmod -wrx d1
#cat d1/f1
cat: d1/f1: Permission denied
#cat d2/f2
hello


Yes, the policy has type_transition statements that dictate how files get created. For example in the policy you might see something like:

type_transition user_t tmp_t : file user_tmp_t;

this means that if a process running as user_t (most user processes on the strict policy) creates a file in tmp_t (generally the label for the /tmp directory) then the file is created as user_tmp_t. This allows people to write files to /tmp and know that they won’t be accessible by other processes that aren’t allowed to read files with that label.

This is one huge advantage over path based mechanisms, if a sys admin logs in via ssh and has a key agent running the socket will be sysadm_sshd_tmp_t in /tmp, so it won’t be accessible by others, even if they have the same UID. However, since the ssh files are fairly random (/tmp/ssh-XXXXXXX) where the X’s are random numbers/letters path based mechanisms cannot protect them and instead rely on DAC to do so.