Weekly edition	Kernel	Security	Distributions	Contact Us	Search
Archives	Calendar	Subscribe	Write for LWN	LWN.net FAQ	Sponsors

Linux security non-modules and AppArmor

Posted Jul 4, 2007 21:53 UTC (Wed) by skybrian (subscriber, #365)
In reply to: Linux security non-modules and AppArmor by farnz
Parent article: Linux security non-modules and AppArmor

It seems like this could be easily solved by disallowing the creation of additional hard links for protected files? If a file is only in one place, mapping inodes to absolute paths might be easier too.

(Log in to post comments)

Posted Jul 5, 2007 8:48 UTC (Thu) by farnz (guest, #17727) [Link]

You've just changed the problem round. What do you mean by protected files?

If you mean files that AppArmor policy covers, then you're implying that you're banning hard links entirely, as in a full deployment of AppArmor, all files are covered by policy.

If you mean files that this program cannot access under the current AppArmor policy, you now have to audit all pairs of programs, and ensure that there is no case where one program which has legitimate access to a sensitive file (e.g. dhcpd in the case of /etc/resolv.conf) can create a hardlink to that file in an area where another process (e.g. an Apache with a security flaw) can create a hardlink to it.

Putting that into a concrete example:

You create policy that prevents Apache from writing /etc/resolv.conf
You create policy that lets dhcpd write /etc/resolv.conf
dhcpd (for whatever reason) creates a new file /tmp/dhcpdXXXXresolv in the process of operation, and fills in the data that will become /etc/resolv.conf
Apache hardlinks to /tmp/dhcpdXXXXresolv, as the security flaw has been exploited
dhcpd moves /tmp/dhcpdXXXXresolv to /etc/resolv.conf

Granted, I'd have had an exploit with or without AppArmor in this case (without AppArmor, Apache could have just overwritten /tmp/dhcpdXXXXresolv or /etc/resolv.conf), but this is exactly the sort of issue a system like AppArmor should protect against; note that I've only posited one buggy program (Apache), and a policy that should confine that process to being unable to edit /etc/resolv.conf, and yet my hypothetical bad guy can still break things.

In contrast, with a label-based system, I'd have a label network-config-file, and all files created by dhcpd would get that label by default. Even though I've not noticed dhcpd's actions in /tmp, Apache can't get access, as it's not allowed to write to network-config-files.

Oh, and again note that the exploitability of this bug depends on partitioning. If I wrote this policy on my home machine (/tmp on a separate partition), I'd not see this flaw at all; if I used it at work (one big / partition), I'd be broken. There's also no easy way to audit a system setup, and confirm that I've not broken the policy; with a label-based system, I just have to check that all filesystems support labelling. With this pathname based system, I have to look at whether my partitioning layout matches the partitioning on the policy developer's system, and whether the differences open holes in policy.

Linux security non-modules and AppArmor

Posted Jul 5, 2007 16:15 UTC (Thu) by skybrian (subscriber, #365) [Link]

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?

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.