On 04/05/2012 03:31 PM, Christian Boltz wrote: > Hello, > > Am Mittwoch, 4. April 2012 schrieb John Johansen: >> A bit of history, and where we are at now > > Thanks for the history lesson! > Can you please store your text (or a link to it) in the wiki? It would > be a pity if it's hidden in the mailinglist archive. > heh well most of it is actually in the spotty release notes but we probably should store some more notes in general with some flow to it, especially with the gradual but not so obvious work towards other features like implicit labeling.
> TL;DR summary from IRC: > The plan is basically that a program initially started as unconfined > can be switched to a profile later. > right >> So what is left to do so we can "replace" the unconfined profile >> - provide a method of marking a profile as immutable (so some >> unconfined or other profiles can be marked as immutable if needed by >> the policy) > > If you combine that with denying write access to the profile in > /etc/apparmor.d/ system-wide, you'll have a really hard time if you need > to change the profile *g* > yep > Besides that, I hope not too many profiles will be immutable - rebooting > a server just to reload a profile isn't really what I want ;-) > OTOH, there's the added security that a root exploit can't abused to > change or remove those profiles. > > Hmmm, the answer if immutable profiles are a good idea or not probably > depends on your level of paranoia ;-) > right, it kind of like the switch to turn off loading modules, if you don't want it. Don't use it >> So what decisions are left to be made? >> - should the unconfined profile show up in profile listings? > > I tend to say no. > What of the default profile? >> - should a profile replacing unconfined be allowed to be called >> unconfined? That is a profile that replaces unconfined isn't really a >> special unconfined state any more, should we not allow its >> replacement to be called unconfined so as to not cause confusion >> there, or do we allow it to avoid confusion caused by the next point > > "unconfined" should mean unconfined - in other words: it should never be > changed. > > Use a profile name like "default_profile" or whatever you like - but not > "unconfined". > I tend to agree, but I wanted to get other peoples impressions I was thinking of just "default" and it is initially set to unconfined >> - should replacing the unconfined profile actual replace the profile >> or just task instance using the profile? That is to say what is the >> behavior of >> >> /foo ux, # does this enter the profile that replaced unconfined or >> does it enter the unconfined profile, or does it fail > > That's as confusing as my (non-random) sig - and shows why we shouldn't > change the meaning of "unconfined". > yep > If you want the new default_profile, use px -> default_profile. > >> same questions for >> >> /foo px -> unconfined, > > I'd make that a parser error - something like "invalid/reserved profile > name". If you want unconfined, use ux. Period. > hrmmm it is a valid profile change and there have been half formed plan to maybe extend the named transition syntax to a list at some point eg. /** px -> one two three inherit, or some such which would be try "one" first if it doesn't exist try "two" then "three" if none of those fallback to inheriting whether we actually ever do that .. >> and for change_profile ->unconfined, > > Argh, this one is trickier ;-) because we have no existing rule syntax > to do that. > > Does it really make sense to allow a program to leave its profile? > I don't really like this idea... > Actually we do, :) (sorry if you missed it, its not been well used but has existed since 2.3 I think) change_profile <executable> '->' <profile>, gives permission for a confined task to use the change_profile and change_onexec api to direct their transitions. the <executable> portion isn't supported at the moment and must be left blank but it will eventually be added to allow restricting potential self directed transitions to a specific executable. In general change_profile should only be used from at least semi-trusted tasks that are setting up confinement or priv-sep for a child or sub task, so it shouldn't be used often but it can be really useful. eg. 2.8 picks up the aa-exec utility that will allow you to launch a task in a specific profile aa-exec -p my_profile /bin/bash generally I think change_onexec and change_profile are used most often from unconfined cases but there are plans to extend pam_apparmor to use it instead of change_hat because it will cleanup the profile structure for using it some. >> - should there be a way to replace the unconfined profiles in all >> namespaces? Currently this would be on a namespace by namespace >> basis. > > See above - if it never changes, there's no need to replace it ;-) > :) >> - should a sub-namespace inherit the "unconfined" profile from its >> parent? Currently namespaces don't inherit profiles but unconfined is >> special and that might be the right decision for them, nor would it >> break current semantics in that it could be said that new namespaces >> inherit their parents unconfined profile (which just can't be >> replaced currently). > > Are you talking about "really unconfined" or "default_profile" here? > well if you were replacing unconfined then it might make sense to change it but if we are talking default I don't think it does unless we are also cloning the profiles. So lets alter the proposal a bit. Every namespace gets a new default profile alias that starts out pointing to unconfined but can be replaced to point to a new profile, and have all tasks using it switch to the new profile as well. I think default should not show up in the profile list but when introspecting the namespace should have it own entry that specifies what profile is the default. -- AppArmor mailing list AppArmor@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/apparmor
