Re: [apparmor] replacing unconfined and doing global policy
Hello, Am Donnerstag, 5. April 2012 schrieb John Johansen: On 04/05/2012 03:31 PM, Christian Boltz wrote: 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. Sounds like you just volunteered ;-) 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? The default profile will be a real profile with (optionally) some restrictions - therefore I'd say it should show up in profile listings. I was thinking of just default and it is initially set to unconfined Sounds good. 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 Interesting idea, but I'd write it as /** pix - one two three, (note the pix instead of px) 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, I know change_profile, and apparmor.vim is my witness ;-) My question was about the - unconfined part - do we really want to allow a program to leave its profile and make it unconfined? I'd vote against it... 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. Sounds good. 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. That sounds like you are thinking to make the default profile like a symlink. I'd make it a normal profile and handle it the normal way. (This includes showing it in the profile list.) Regards, Christian Boltz -- cboltz when will you release it? jjohansen [...] if you want I will work on getting it up tonight cboltz yes, please do it before I find another bug ;-) jjohansen hehe, extra incentive to get it up quick :) [from #apparmor] -- AppArmor mailing list AppArmor@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/apparmor
Re: [apparmor] replacing unconfined and doing global policy
Would we have to also remove controls like only unconfined can reload policy? Or did we do that already when cap mac_admin was introduced? Would we want to add new policy language to provide fine-grain control of cap mac_admin? -- AppArmor mailing list AppArmor@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/apparmor
Re: [apparmor] replacing unconfined and doing global policy
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. TL;DR summary from IRC: The plan is basically that a program initially started as unconfined can be switched to a profile later. 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* 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 ;-) So what decisions are left to be made? - should the unconfined profile show up in profile listings? I tend to say no. - 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. - 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. 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. 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... - 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? Regards, Christian Boltz -- Wouldn't the sentence 'I want to put a hyphen between the words Fish and And and And and Chips in my Fish-And-Chips sign' have been clearer if quotation marks had been placed before Fish, and between Fish and and, and and and And, and And and and, and and and And, and And and and, and and and Chips, as well as after Chips? -- BSD fortune file -- AppArmor mailing list AppArmor@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/apparmor
Re: [apparmor] replacing unconfined and doing global policy
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,
