On 6/18/19 10:08 PM, Abhishek Vijeev wrote: > Hi, > > I think I now understand the meaning of 'mediation points aren't in process > context'. I've been trying to use Netfilter hooks to confine a process' > network capabilities, but realized that the point at which the hook is > invoked is not in process context, and thus, the network packet cannot be > traced back to the process from which it originated. > > Since you mentioned mechanisms to cope with this, could you briefly list them? >
12345678901234567890123456789012345678901234567890123567890123456789012 AppArmor doesn't need to mediate at the process context level (there are some things like the owner conditional that require it) instead mediation is done via the subject and object label. The object label for networking within the kernel stack is handled by the secmark. This does require conversion between the secmark and apparmor's internal label structure. Packets going off machine loose the secmark and incoming packet are unlabeled. iptable rules can be used to set a secmark and thus a labeling on packets. It is possible to preserve a packet labeling on the network by using cipso, calypso, or xfrm but we don't have plans to use these atm. The subjective label is harder, where possible we want to use the processes label, or one specified by process' confinement. However in cases where this isn't possible we can use the socket labeling for all the processes that share the socket. This does require us to track the socket label as a compound label, where it is updated to the process context label when it is passed/inherited between process contexts. When this happens the permission check is basically done for each process context that shares the socket. This does however have limitations, in general the fs and network system like to assume permissions on a socket are fixed at open/connect. And there are complications around network namespaces. Most of the issues can be worked around by specifying a compound label early (has not landed yet), and using delegation (again not landed yet). AppArmor's fine grained network rules are very much a wip, as to do it right we need to land more core changes. > Thank you. > > On Jun 13 2019, at 5:48 pm, Abhishek Vijeev <abhishekvij...@iisc.ac.in> wrote: > > > > 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/ad408d62-3b92-4d3b-ad7b-961e64ead...@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 > > Sent from Mailspring > -- AppArmor mailing list AppArmor@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/apparmor
