On Jun 13 2019, at 3:07 am, Seth Arnold <seth.arn...@canonical.com> wrote: On Wed, Jun 12, 2019 at 12:32:53PM +0000, Abhishek Vijeev wrote: Hi,
I have a few questions about AppArmor's code and would be grateful if you could kindly answer them. [I've stripped your urls of some get-mail-spring style links] 1) The documentation at this link https://gitlab.com/apparmor/apparmor/wikis/AppArmor_Core_Policy_Reference#address-expr mentions the possibility of specifying a network rule as "network tcp src 192.168.1.1:80 dst 170.1.1.0:80". However this doesn't work, and after a little digging, I found out that the productions rules for this policy were available only in the grammar specification of AppArmor 2.1 (line number 670 of https://gitlab.com/apparmor/apparmor/blob/apparmor-2.1/parser/parser_yacc.y ). I find this extremely useful, and am considering trying to add this to AppArmor as part of a larger project. Could you kindly clarify the reason for its removal? Were there any hurdles that made it difficult to accomplish this? Fine-grained networking controls have been on the most often desired features for perhaps fifteen years. Some small portions of fine-grained networking may be simple enough to implement as a project. Controlling bind, listen, and connect might be straight forward enough. However, a more fully-featured implementation that mediates sockets passed in, or sockets shared among multiple domains, etc., would require significantly more work to implement. Quite a lot of the mediation points available in the Linux kernel aren't in process context. There's mechanisms available to cope with this, but they're not nearly as easy to use as doing the mediation when running in process context. According to my current understanding, the mediation points used by AppArmor and other security modules are the hooks made available by the LSM hook interface. Could you kindly clarify the meaning of 'mediation points aren't in process context'? Also, could you briefly list the other mechanisms to cope with this problem? I'm rusty on this at this point, but if you search lwn for secmark, secid, you'll probably find some useful articles. (Figuring out which ones are useful is left as an exercise for the reader. :) Sure, thank you. I'll look up secmark and secid. 2) At what stage during the kernel boot process does AppArmor load the profiles? And from where does it obtain them? (am I correct in understanding that the profiles are stored in /sys/kernel/security/apparmor/policy ?) The kernel boot process does not load any apparmor policy. Policy is loaded by userspace. If you want to have a confined init, you'll need to modify your initramfs to load policy before switching to the system init. Most distributions use the sysv-initscripts, or a fork from them from years ago, and some systemd unit files to call the initscripts. These usually load policy from /etc/apparmor.d/ but packaging systems like click and snap loaded policy from elsewhere, and libvirt and snapd (among others) will dynamically generate and load policy as needed. I see. Is it not possible to confine init by just changing the set_init_ctx( ) function (https://github.com/torvalds/linux/blob/master/security/apparmor/lsm.c#L1522<https://link.getmailspring.com/link/6c730a91-bac3-4a5f-8d02-4be24c6e0...@getmailspring.com/0?redirect=https%3A%2F%2Fgithub.com%2Ftorvalds%2Flinux%2Fblob%2Fmaster%2Fsecurity%2Fapparmor%2Flsm.c%23L1522&recipient=YXBwYXJtb3JAbGlzdHMudWJ1bnR1LmNvbQ%3D%3D> ) to set a different profile by default? 3) Why does function 'aa_alloc_profile( )' allocate extra memory ? It seems to be allocating memory for 3 objects of type 'struct aa_profile'. (line number 262 of https://github.com/torvalds/linux/blob/master/security/apparmor/policy.c ) This is allocating space for a single struct aa_profile and two pointers: https://github.com/torvalds/linux/blob/master/security/apparmor/include/policy.h#L162 struct aa_profile { struct aa_policy base; struct aa_profile __rcu *parent; /* ... */ aa_label label; }; https://github.com/torvalds/linux/blob/master/security/apparmor/include/label.h#L134 struct aa_label { struct kref count; struct rb_node node; /* ... */ struct aa_profile *vec[]; }; The pointers are for the final vec: https://en.wikipedia.org/wiki/Flexible_array_member Thank you. I did not know about flexible arrays. Thanks
-- AppArmor mailing list AppArmor@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/apparmor
