Linux security non-modules and AppArmor [LWN.net]

Linux security non-modules and AppArmor

Posted Jul 5, 2007 16:15 UTC (Thu) by skybrian (subscriber, #365)
In reply to: Linux security non-modules and AppArmor by farnz
Parent article: Linux security non-modules and AppArmor

If policy is based on paths, then it seems like hard links between any two paths that have different security policies has to be disallowed (for example, between /etc and /tmp). Otherwise you've got files that appear under more than one security level. Any kind of copy between files at paths with different security levels untaints the data.

A taint-based system does seem more appealing if it could be made to work. It occurs to me that we have something close to that already, except that the security label is the owner and group of the file. The issues with setting the label for new files are similar to deciding what the owner, group, and umask should be for a new file. Maybe this would be more popular if security labels were something familiar? A special kind of group?

(Log in to post comments)

Linux security non-modules and AppArmor

Posted Jul 6, 2007 8:29 UTC (Fri) by farnz (guest, #17727) [Link]

You're still facing two problems with hard links:

I can create a hard link in /tmp to another file in /tmp, and then (assuming suitable partitioning), someone else can move the file or the hard link to /etc. The move creates a hard link from /tmp to /etc, so you'd have to ban use of rename(2) to atomically move files from one location to another.
Security policy is per-application; any path has multiple different security policies applying to it, depending on which application is accessing it. Working out the union of policies, and only allowing hard links if the union of policies is "safe" is a hard task.