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
