[apparmor] create permission

John Johansen john.johansen at canonical.com
Fri Dec 17 08:57:37 GMT 2010


On 12/16/2010 11:28 AM, Christian Boltz wrote:
> Hello,
> 
> Am Donnerstag, 16. Dezember 2010 schrieb John Johansen:
>> So apparmor has had a create permission for a while now, but it has
>> not been directly expressible in policy.  I would like to fix this
>> however the letter c which is a natural fit for create (and is what
>> is used by the kernel when reporting it) is used as an x modifier
>> for children profiles (cx, Cx).
>>
>> So to expose the create permission we have a few possible choices.
>> 1. choose a different letter
> 
> That would be my favorite solution.
> 
> What about "n" as in "new file" or uppercase "A" (similar to lowercase a 
> for append)?
> 
> Not as obvious as c would be, but both variants still have a meaning.
> 
Seth just reminded me of another possibility which is slightly confusing,
but might be cleaner in the long run.

Remove c from x, and replace it with something else (perhaps ^ as hats
are just a variant of a child profile).

I think we can entertain this possibility for two reasons.
1. I don't think children profiles are in wide use, in fact I would be
   surprised if anybody is using them.
2. We are going to be adding a version tag, and that provides an
   opportunity to break a few things in a clean way

>> 2. use c and either require it is either
>>    2.1 not used immediately to the left of x if it is to mean cx.
>>        ie. xc == create and execute
>>            cx == child profile transition
> 
> I'm afraid that's more confusing than using a different letter.
> (And I don't even want to know how "interesting" it would make vim 
> syntax highlighting...)
> 
agreed that solution just sucks

>>    2.2 not used in a rule that has an x transition
> 
> create and execute for the same file sounds scary (same for write + 
> exec) - but that's a very good reason to make this possible. (The 
> alternative would be *xw instead of *x+create, which would be more 
> scary.)
> 
>> 3. exposed through long for permissions, ie. using the create keyword
>>    /foo create px,
> 
> No keywords for file permissions, please. That would be inconsistent 
> syntax-wise (all other file permissions use letters).
> 
Actually I think that is almost unavoidable at this point, but that is
because the actual set of permissions is much wider than is currently
exposed.

The letters are short hand and are what would be used commonly but it
would be good to expose some of the other functionality.

If your curious the larger permission set is
  create - permission to create a file
  delete - permission to delete a file
  rename - a special rename permission that allows moving a file without
           being able to read/write the file data.
  read - permission to read a files contents
  meta-read (attr-read???) - permissions to read a files meta data
           (attributes)
  write - permission to write data to a file, including extending the
          file (implies append)
  append - permission to append new data to the file (extending the file
           size), no data overwrite. Must be used in conjunction with
           application opening the file with O_APPEND, otherwise the
           file open will fail.h
  trunc - permission to truncate (shorten the file)
  meta-write - permission to write a subset of the files meta-data not
               controlled by specialized flags
  chmod - permission to change DAC file permissions on the file
  chown - permission to change file owner
  link - permission to link to the file, when used with ** determines if
         permissions apply to an entire subtree
  lock - permission to lock a file, combines with append || write to
         take exclusive lock
  mmap_r - mmap a file readable
  mmap_w - mmap a file writable
  mmap_x - mmap a file executable
  exec - permission to execute a file

with the current permissions mapping to
  r - read, meta-read, mmap_r
  w - create, delete, trunc, write, meta-write, chmod, chown, mmap_w,
      partial rename (where it implies partial source rename permissions and
      full destination renamed permission)
  a - append, create
  l - link (may be combined with other permissions to determine if allowed)
  k - lock (combines with write to determine if exclusive lock is allowed)
  m - mmap_x, mprot_wx
  x - exec, (if ix then also mmap_x)

with x permission have the modifiers
  pPcCiu



More information about the AppArmor mailing list