Zbr's days.
←June→
Sun Mon Tue Wed Thu Fri Sat
1 2 3 4 5 6 7
8 9 10 11 12 13 14
15 16 17 18 19 20 21
22 23 24 25 26 27 28
29 30          
←2008→
Months
Jan Feb Mar
Apr May Jun
Jul Aug Sep
Oct Nov Dec

About :: TODO :: Blog :: RSS :: Old blog :: Projects :: GIT :: Gallery :: Notes

Mon, 02 Jun 2008

AppArmor and path-based security approaches vs object bound policies.

- So again, can you offer an alternative?
- Just give up on this dumb idea completely.
It is not about AppArmor in general (although maybe about it too), but about security hooks which provide path information into inode callbacks. There are pros and cons for this decision, but things look like path based security hooks will not be accepted.

There is a really trivial way to fix it. No kidding, it is simple: create own name cache and do not bind it to dentries, but instead index it by inode number. This allows you to have whatever you want callbacks and information in stricktly bound VFS operations. Need to have path info in ->inode_create()? Put it into own tree indexed by inode number for parent inode, lookup that data in security hook and make a decision. Yes, it is slower, but active security was never a fast solution. It is still against the rules others created for security based systems, but still formally it in the all boundaries of the created (maybe ugly for someone) interfaces.

And I will not point to project, which already uses such approach in different area though :)
It is interesting to implement your ideas not by breaking something (although sometimes it is need, but that's likely an exeption or when you are hacking deeply internal kernel part), but instead by hacking around existing limitations.

/devel/fs :: Link / Comments (4)

M wrote at 2008-06-03 10:57:

Hi,

I am a SELinux user and I generally believe that the object model is better than path based. But I completely do not understand VFS maintainers - why they are blocking Miklos patches? They are not forced to use AppArmor. I do not see any problem for which AppArmor should not be included in the Linux. If someone wants to use a better MAC, then SELinux is the best choice. If someone wants an easy-to-use MAC, then AppArmor is almost as easy to use as SELinux ;). It is a matter of choice.

I think it is a great flaw of Linux that few people can effectively block the inclusion of feature just because they do not like it's approach.

Regards, M.

Johannes Berg wrote at 2008-06-03 12:41:

@M: I think that's a perfectly fine reason to block it since the VFS maintainers are those who have to put up with the code forever, while Miklos can just dump&run. And if the VFS maintainers hate the code, they aren't going to be motivated to fix it, which will make it very painful for all involved in the long run, possibly even making the VFS maintainers drop the subsystem (if they were somehow forced to accept those patches.) Similar things happened with the x86 32/64 unification, the previous maintainer didn't like that approach and when it was forced into the tree he stopped doing maintenance.

sp wrote at 2008-06-08 11:07:

I think an easier method is to just implement that path based security as a stackable file system.

don't need to make any vfs changes then, can all be captured in the stackable fs.

though, would take more effort to set the system up correctly to use it.

Zbr wrote at 2008-06-10 23:52:

Stackable filesystems have (lots of) own problems, that is why there is (will be?) no unionfs or its analog in mainline.

Please solve this captcha to be allowed to post (need to reload in a minute): 19 - 29

Comments are closed for this story.