-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 15/12/15 18:45, Steve Beattie wrote: > Hey Colin, > > On Tue, Dec 15, 2015 at 05:29:43PM +0000, Colin Ian King wrote: >> So far I've been successful from the info you have provided. I've >> compiled a policy into a binary blob and got it loaded into a buffer and >> successfully loaded this into the kernel. > > That's great! > > I'm curious which elements of apparmor you're trying to stress with > what you're adding to stress-ng. The general process outline goes like > this: > > policy -> apparmor_parser -> kernel policy load interface -> policy enforcement > > The first phase, of turning a textual policy into a binary blob, > occurs entirely in user space, and is likely of little interest to you . > > The second phase, where a binary policy blob is loaded into the kernel > and stored in kernel data structures is certainly a valuable place to > look for problems[1], though it is at this point in time considered a > mostly trusted interface (you must have CAP_MAC_ADMIN to make use of > it). However, future plans include this becoming not true, and there > currently exist tools that auto-generate policy based on templates, > so it's still a sensitive interface. It seems that this is the area > you're focusing on?
Currently, I'm just piling a load of different stressors onto the kernel interfaces using the aa_kernel* userspace API, I've only just started today, so it is very early "work in progress", c.f: http://kernel.ubuntu.com/git/cking/stress-ng.git/tree/stress-apparmor.c? id=1fdb0ca847db3840ab47daae04384608db0149bf I'm currently hacking some code to force EPROTO failures by twidding the data being passed to the kernel, and I'll be focusing on the raw compiled profile blob for the moment. > > It also seems to me that stressing the enforcement side of things > is valuable, as well as the related interfaces around policy > domain transitions (changing policy or not on exec(), change_hat(), > change_profile()). We also have relatively recently added interfaces > (which I think John referred to earlier) around querying confinement > status and querying permissions directly. Exercising and stressing > these direct interfaces would be great; stressing access mediation > would be indirect via regular syscalls (e.g. open()). OK, that's a good place to focus on. > > There are some known existing performance limitations in some of the > interfaces; for example, change_hat() on a policy with 5 digits of > hats is slow, due to the in-kernel data structures used. > > Thanks again for your work on this, both in general for stress-ng > and for specifically adding apparmor to it! > > [1] For anyone looking for an interesting security relevant project > to take on, extending one of the (syscall) fuzzing tools out > there to exercise the policy loading interface and other apparmor > kernel<->userspace interface layers would be a great thing to do. > -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJWcGGnAAoJEGjCh9/GqAImZSQP/0zqHXnuHRU/8EMrjESTOfrq 99fSX2xfqjpiNE12FlHuXJiQKmxqToIHOf4/r+meHO9JGD26ssy3+ve+SvLRoAwF fFrsE7mp0MRNNM49NJEH1YOnkba2qdR0PpoMhXeCd4DL2sQCrw9uvmIag0WGdtrL d8zSDBm5sNiBSlngrtlKXhhyQqdHVuAMfPMfCbh1QJLXmaWU6J/RAMlZNcCUyQHo 5n+yg/7V5eP10evFlpGzEgpoZWyEZGWew4y3OqRIKDCa1WE/IHKSKzWNO+nU4fMr jIRP3oNPCJvdub26WSpBGIvzUj8FBCukQsX0RsmNlAOC3EZL0yhqsCSjNXHs7i1t 3X/ofz2bR2n6rkeYMcjCdTo2fsYXMoJ3NrGzAgBMM5sIWOt9SlOjz2NuVAdbrz/z FAllRQKAV7gnsLtYlWpWOwWmf1ae3o1aa8C7/x1RzOmpIj5s5fn/Ighw6VSmf3ub iJlSaCqHBmWAa8OQCGPKkfpSIAn/MpVApt6Au7W7xKQSzrVr3nqlKwMRHICChyPt QrxOqAySYSCyGWEZO0ipcVVorjUp1JSizq+90t0lrrhZZ0NBXLgIMjv2IYRVftsF bp8sxwbXjMMBBb54PYyf4R0/Xcvbzoe4lvNf7WA38O8FIjtWgbJNI1Rjm8Ky4pOp t8pIhN9EhZL2UfWVDqea =reFM -----END PGP SIGNATURE----- -- AppArmor mailing list AppArmor@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/apparmor
