Linux security non-modules and AppArmor
Posted Jul 5, 2007 8:48 UTC (Thu) by farnz
In reply to: Linux security non-modules and AppArmor
Parent article: Linux security non-modules and AppArmor
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.
to post comments)