Hello, I have some feedback and questions before the meeting tomorrow ;-)
Am Freitag, 6. Februar 2015 schrieb John Johansen: > Anyways profiles in the unconfined mode show up as > profile (unconfined) > > while the current behavior of the unconfined profile, which is the > standard default profile remains as > unconfined Can both ways (one process in state "foo (unconfined)" and another one just "unconfined") exist at the same time on a system? Or will programs executed with an Ux rule also get "foo (unconfined)"? > this was done for backwards compatibility with tools but could be > changed for consistency unconfined (unconfined) Well, for real backwards compability, having just "unconfined" would be even better ;-) > I don't think there is really a need, unless anyone objects, we just > need to make sure the tools are updated to handle the new unconfined > mode. Right. BTW: Do you know of external tools that read the proc interface (and could possibly break)? > we could report the full mode names but that would result in longer > mode strings, leaving less remove for the profile names, and actually > require more work to update the parsing of our userspace tools. > Keeping it short also has benefits for none apparmor specific tools > (eg. ps -Z) Agreed, the short mode is better for various reasons and also easier to parse. > the third issue to make sure we nail down is around namespace > visibility. With stacking it becomes possible to have profiles from > different namespaces confining a task simultaneously. For example the > host might want to limit what an lxc container can access, and the > lxc container being run as a virtual OS may have its own policy on > the processes that are running. So for a host using the confinelxc > profile on lxc, and an lxc process running apache inside a policy > namespace of containerA, when queried from the host we could have > something like > confinelxc//&:containerA://apache (EE) > and when queried from in the container, only > apache (enforce) > > that is the interface is virtualized along the namespace hierarchy, a > task can only see anything at or below its current namespace. The > question is, is this the default that we want for the proc interface > or should it only report the profiles from the current namespace? ie. > for the above example, either > confinelxc (enforce) > or > apache (enforce) > dependent on who does the querying In the interest of backwards compability, I'd vote to only report the profile from the current namespace in the proc interface. > If we decide to make the proc interface show only the current > namespace profiles we would need to add to the apparmorfs interface a > way to query the hierarchy, as it does have its uses. Yes. The good thing is that we can do everything we need without breaking something, because that will be a new interface. BTW: Will/should the "child" namespace be able to get information about its parent, or should only the "parent" know about the child? (I'm wondering if allowing to see the child that it's running inside lxc/$whatever brings any security concerns.) > Now to the writable end > currently apparmor uses all potential character including embedded > \000 characters as part of its interface, ideally we don't want to > change this (for backwards compatibility reasons) but if it becomes > necessary so there can be better unified LSM interfaces we need to > start pondering what could be done. I don't have any specific issues > or recommendations, I just want to point it out as a potential issue > and that you might want to look into the LSM discussion (mentioned > above) As long as the interface understands the "old" \000 and the "new" way (however that looks), I don't see a real compability problem. We "just" need to extend the AppArmor code so that it understands both, and that the "new" way is easily distinguishable from the "old" way. Regards, Christian Boltz -- Sind wir denn hier im Kindergarten? Kaum is Mama weg, schon haut Ihr aufeinander rum. Nu is Mama (ich) wieder da und jetzt aber wieder sinnig hier!! [Jessica Bleche in suse-linux] -- AppArmor mailing list AppArmor@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/apparmor
