Re: [apparmor] replacing unconfined and doing global policy
On 04/06/2012 08:08 AM, Christian Boltz wrote: >> >> 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") > Either works for me I can understand the desire to leverage the existing syntax 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 '->' , > > 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... > yeah I was positive you did but went into a long description anyway, and then missed out add the last little bit the reason we allow switching to unconfined is two fold. 1. To not restrict what policy authors can do (much like giving access to ux. 2. So that it can be specified when changing into a new namespace eg. /foo/bar px -> :ns2:unconfined, change_profile -> :ns2:unconfined, Often when changing namespace the correct solution is the unconfined or (default profile) >> 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.) > Hrmmm sort of, it certainly could manifest it self as a symlink but at least in implementation it would need to track the tasks using it separate from those using unconfined. As to whether its in the list, that depends a little on the behavior, does a task that is assigned the default profile, show up as default. Or does it show as the profile it is referencing. So if default is set to unconfined then tasks assigned to default get listed as being unconfined. When default gets replaced they now show up as belong to the new default. Basically we are proposing splitting the notion of default from unconfined and we need to nail down exactly what we want. Do we want to add new transition types dx pdx or some such, when people used ux, pux did they really mean unconfined or should it be the default, etc. -- 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 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 '->' , 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 -- when will you release it? [...] if you want I will work on getting it up tonight yes, please do it before I find another bug ;-) 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
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 '->' , gives permission for a confined task to use the change_profile and change_onexec api to direct their transitions. the 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 na
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 09:27 AM, Seth Arnold wrote: > 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? right the unconfined controls where replaced with cap mac_admin, but we still want to have better controls than that so the users can load their own policy (at some point in the future) -- 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
