[apparmor] profile naming and attachment

[Steve Beattie]

On Wed, Nov 17, 2010 at 05:19:17PM -0800, John Johansen wrote:
> = Profile naming =
> I would like to extend to extend the syntax slightly to allow for a name to be
> specified separate of the profile attachment.  The syntax extension would be of
> the form
>   profile [name] attachment [flags] { }
> 
> so the name would be optional and only available when using the profile keyword,
> which is currently used to specify profile that don't have an attachment
> specification.  If a name was not specified the attachment specification would
> be used for the name as it currently is.  For our firefox example this would be
> 
>    profile firefox /usr/lib/firefox-3.6.12/firefox-*bin { }

+1 from me, also. I'm also assuming that namespaces would be supported
in naming profiles.

> = multiple attachment specification for profiles =
> This one has been discussed in the past and I don't believe it is needed
> anymore.  The idea was to allow a profile to have multiple names.  So it
> could attach to multiple programs.
> 
> ie.  /bin/foo /usr/bin/foo {  }
> 
> however it then introduced the problem of what to do with replacements and
> removals.  Was the first name the handle that would be used to replace and
> remove the profile, or would the profile be removed on a per name bases.
> What if the profile was split in user space and reloaded etc ...
> 
> With profiles names now allowing pattern matching I believe we have a better
> solution.  We retain single name behavior and the multiple attachment is
> handled by the pattern matching.
>   /{bin/foo,usr/bin/foo} { }
> 
> combined with the first proposal of allowing profile names separate of the
> attachment and we get a nice clean profile name to work with and multiple
> attachment
> 
>   profile foo /{bin/foo,usr/bin/foo} { }

I'm okay with supporting this syntax; however, to me it's a less than
ideal way to enumerate multiple binaries that we want to apply the same
profile to. I have a vague recollection of you and I discussing a way of
specifying mappings, though I don't recall any specific syntax. But to
get the general gist across, something like:

  map /usr/bin/foo -> profile foo
  map /bin/foo -> profile foo

  profile foo { ... }

Are you no longer interested in supporting this kind of language?

(At a meta level, this discussion makes clear to me that what we have
is an implicit profile for the unconfined state, and our profile
definitions are the px permission rules for it. Conceptually, maps
thus would be cx statements for unconfined. It's interesting to me
to think about things this way, anyway.)

> = conditional profile attachment =
> The final idea I want to raise is making conditional rules available to profile
> attachment.  This one is a little further off and needs some more thought.
> 
> Currently we have the single conditional of file ownership
> ie.
>    owner /foo/bar r,
> 
> and soon it will expand to allow things more like
>    owner=(jj smb)  /foo/bar r,
> 
> 
> 
> I think it is worth making this functionality available to profile attachment
> as well.
>    eg.
>      profile confined_user user=guest /bin/bash { }

(As an aside, I'm glad that you dropped re-using the owner keyword
in your proposal here, as I think it unnecessarily confuses things.)

> Thus only attaching the profile for specific users, etc.
> 
> this could some what replace pam_apparmor but I am not sure at this time
> that we would want to or what would be the best uses for this functionality.
> Eg. using pam with the proposed change_onexec extension would allow updating
>     what users get the confinement without having to reload policy
> 
> Basically the ability will be present in the enforcement engine its just
> a matter of where/when we choose to expose it.  Also just because we
> choose to expose it doesn't mean we have to use it in a given situation.

I appreciate the desire for flexibility, but I would like to see a
stronger use case scenario than pam-free systems (though I acknowledge
they do exist), and I think we have higher priorities.

Thanks for writing this proposal up, John!

-- 
Steve Beattie
<sbeattie at ubuntu.com>
http://NxNW.org/~steve/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
Url : https://lists.ubuntu.com/archives/apparmor/attachments/20101119/a329f2f5/attachment.pgp