Hello. Indan Zupancic wrote: > If MAC can avoid all that, then why can't it also avoid tampering with /dev? If MAC implementation handles filename and its attributes pair, this filesystem is not needed. But I don't know MAC implementations that handle this pair. SELinux's granularity is "allow foo_t to create block device file in dev_t directory". TOMOYO's granularity is "allow foo to create block device file named /dev/sda1". Both don't enforce filename and its attributes pair, thus the attacker with root privilege can create fake device files if he/she is permitted to create device files by MAC's policy. It would be possible to handle this pair within MAC's policy by expanding their policy syntaxes, but offloading this handling on filesystem can make MAC's policy syntax simple because filename and its attributes pairs are conventionally constant. You won't let foo_t to create /dev/sda1 with block-8-1 attributes and let bar_t to create /dev/sda1 with block-8-2 attributes, will you? You don't want to describe attribute information to every entry in MAC's policy, do you? It is redundant to describe this attribute enforcement information in MAC's policy unless you want to break conventional filename and its attributes pairs. > What security does your filesystem add at all, if it's useless without a MAC > doing all the hard work? Allow / partition to be mounted for read-only mode. Allow /dev partition to be enforced filename and its attributes to avoid /dev/null spoofing (create /dev/null as a regular file for eavesdropping purpose). This filesystem adds filename and its attributes enforcement, but it is overridable if this filesystem is used without MAC. This filesystem adds unoverridable filename and its attributes enforcement if this filesystem is used with MAC. Regards. - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
