[Apparmor-dev] AA3 - file rules

[Christian Boltz]

Hello,

Am Donnerstag, 1. Januar 2009 schrieb John Johansen:
> 3. Pathnames with using regular expressions

>   - . will match any character except '\0'

Including '/'?

> 4. Special kernel variables

>     @{tid} - task id

I never heard of a "task id" - what is it used/useful for?

> 5. Extended owner rules

>     #specify an owner uid instead of an owner
>     owner=(#101) /some/file rw,

I'm not really happy with using the '#' char because it is also used for 
comments (and might make syntax highlighting more difficult).

useradd(8) says:

    The account name must begin with an alphabetic character and the 
    rest of the string should be from the POSIX portable character class 
    ([A-Za-z_][A-Za-z0-9_-.]*[A-Za-z0-9_-.$]).

This means that usernames _have to_ start with [a-z] and are therefore 
easy to distinguish from uids. No need to add '#' ;-)

>     #specifying the owners in a variable
>     owner=(@{foo_users})  /some/file  rw,

What about allowing users that are members of a specific group, like 
everybody in "users"?

>   One of the open questions is if the negative case is needed and if
>   so, what syntax should be used.
>
>     owner!=(tom, dick)  /some/file  rw,  # allow access to /some/file
> if # not owned by tom or dick
>
>     !owner /some/file rw,                # allow access to /some/file
> if # not owned by the current # fsuid

This could be useful - for example, you could forbid wwwrun to read 
files owned by wwwrun to prevent reading/executing code that has been 
uploaded via webapps. (Well, file/directory permissions can be used to 
prevent uploads at all, but having it as apparmor rules allows more 
detailed access rules. And in several cases, uploads are needed in 
general.)

The idea I have: Force all *.php files into a subprofile that forbids 
reading of wwwrun-owned files (aka files uploaded using web apps), 
while the main profile (for all static files) allows uploaded images 
etc. to be delivered to web browsers.

Real life example: a customer had a forum which allowed upload of avatar 
images - for example files like "myphoto.php"...

>   One of the open questions is if a full profile reload is necessary
> or whether a special table for user information should be loaded.  So
> that updates to the user database rely only on loading the current
> user database.

Depends on the time needed for a full reload IMHO ;-)

> 5.1 change of owner syntax?
>   The current owner rule syntax is not as explicit as it could by
> that the rule is conditional on ownership.  I am unsure if the
> current syntax is sufficient or whether tweaking the syntax would be
> helpful for the average user.
>
>    eg.
>      owner /foo/bar rw,
>
>    could be rewritten as
>      if owner /foo/bar rw,
>
>    It is a small change but does emphasize that the rule is
> conditional on file ownership.

I think "owner" is sufficient.
(And people who start reading or modyfying their profiles by hand should 
have some basic knownledge about them - some of the letters used for 
file permissions are less self-explaining than "owner" ;-)

> 6. Attrs and xattr permissions

>   6.1 chown
>   File chown could be limited by either a per profile mask of uid or
>   it could be done per file.
>
>     chown (tom, jane),			# profile level mask

aka
    /** chown(tom,jane),
;-) - no need to allow chown per profile *g*

>    vs. file level
>      /some/file chown=(tom, jane),
>    or
>      chown=(tom, jane) /some/file,

Both variants look good.

>    or
>      chown /some/file (tom, jane),

Not this syntax, please. The chown keyword and the list of usernames 
should be kept together.

>   If done at a per file level, it will allowed to be conditional on
> file ownership and allow for chowning to any user.
>
>     owner /some/file chown=(tom, jane),
>     owner /some/file chown=(*), #allow chown to any user if file owner

Checking the current file owner is a very good idea - and IMHO more 
imporant than checking/restricting the new owner. That's one of the 
examples where the proposed new owner=... syntax is really useful :-)

>   7.1 Mount rules

>     mount permissions type device -> /path,
>
>   or more closely adhere to the mount command form of
>
>     mount permissions [-t type] [-o options] device -> /path,
>
>   The mount permissions will cover bind mounting, suid, etc.  And
>   pattern matching will be allowed in each part of the rule (type,
>   option, device, /path).

How would an example rule look like?

How are you planning to handle different mount options, for example "ro" 
vs. "rw"? Will "rw" also allow to use "ro" instead?

To make things interesting: Which keywords/options would a * in the 
option part allow? Would * include things like suid, dev and bind?

>   It is currently undecided on how best to make mount rules
> conditional. On the euid, the fsuid and /path, device owner?

Device owner might be a good idea ("owner mount ..."). And of course the 
path of the device and the mountpoint.

> 9. Symlink permission
...
>   My current inclination is to go with what I think is the least
> complex solution which is mapping it to the r permission and having
> it always enabled.

Please keep interesting ;-) disk layouts in mind when deciding this.
For example, my /var is a symlink to /home/var (which is on my encrypted 
home partition).

Currently I can "update" all profiles by adding a simple alias rule to 
tunables/global:
    alias /var -> /home/var,

I don't want to change each profile just because I moved /var around, so 
I'd like to have this easy way also in future versions of apparmor.


Regards,

Christian Boltz
-- 
         .:  Schneewittchen & die Pfälzer Waldconnection  :.
        Ein polit-kabarettistisches Märchenstück mit viel Musik
  gesungen & gespielt von Mitgliedern der Landjugend RheinhessenPfalz
18.1.2009 Berlin - 6.2.2009 Neustadt - Infos: www.LJ-RheinhessenPfalz.de