[apparmor] mount rules

[Seth Arnold]

On Tue, Dec 13, 2011 at 10:23 AM, John Johansen
<john.johansen at canonical.com> wrote:
> So the question is basically what should mount rules look like.  The mount
> command is a mess and has tons of options, do we want to mimic it as its
> what people will be used to or try for something cleaner.
>
> Basically what I have so far is
>
>  [audit] [deny] mount [options=<options>] [type=<type>] [(<device>|<src>) ->] [<dest>],

I have to admit that I haven't thought specifically what the _syntax_
should look like -- I've just wanted the feature. Pity, since this is
obviously far more difficult than I ever gave it credit.

One _gigantic_ problem -- well, as far as I'd like to see mount rules used
-- is that the administrator can't use the udevd-provided symbolic links
in /dev/disk/by-{id,path,uuid}. I _really_ want whatever solution we come
up with to support using these symbolic links in some fashion. I know that
sounds heretical, but consider these use cases:

- I want to confine some stupid automounter program to read-write mounts
  for my camera's sd card. (/dev/disk/by-id/....) I don't want that stupid
  automounter to _ever_ be able to mount anything else, ever.

- I want to use pam_apparmor to confine all my users in the group "pvtfc"
  to _read only_ USB mounts but allow users in the group "officers"
  read-write USB mounts. Forbid all other SCSI mounts, forbid all
  NFS/CIFS/bind mounts. (/dev/disk/by-path/....)

- I want to confine Calibre to read-write mounts for my Sony Reader.
  (/dev/disk/by-id/... or /dev/disk/by-uuid/....)

- I want my data center operations staff to have privileges to rotate
  through a series of specific backup disks. (/dev/disk/by-uuid/...)

We don't _have_ to use the symbolic links, but they are _extremely_
convenient (and when I found these, I lost a lot of my hatred for udevd)
and very well known.

Could this problem be solved easier if we provide an inotify-based or
udevd-event based daemon that labels device nodes as they are added, and
then perform the mount permissions checks based on device labels?

We could probably also solve this problem using kernel-side variables to
represent different device "names" as they come and go, but the labels
feel like they might be easier to use.

>
> eg.
>
>  mount,   #Grant full mount access
>
>  mount type=ext3,   # allow mounting ext3 filesystems anywhere
>
>  mount type={ext*,vfat} /dev/sda2 -> /media/**,  # allow mounting /dev/sda2 if its any ext3 or vfat anywhere in /media/
>
>  mount /media/**,  # allow mounting anything, anywhere in /media/
>
>  mount options={atime,auto} /media/**,
>
>  mount /foo/ -> /bar/,
>
>
>
> eg. Allow mounting anything unless it is procfs, sysfs,
>
>  mount,
>  deny mount type=procfs,
>  deny mount type=sysfs,
>
> or the two deny rules could be combined into a single rule
>  deny mount type={procfs,sysfs},

There's a _lot_ of kernel-provided filesystems: sysfs, proc, cgroup,
cpuset, devtmpfs, debugfs, securityfs, devpts, binfmt_misc, that would
probably be wise to forbid to "most programs". Denying specific mount
types makes some sense, but .. I fear it'd be "most of them" in practice.

It'd be easier to handle this case if we _also_ provided some abstraction
for 'dev' vs 'nodev' filesystems:

deny mount type=nodev

Allow mounting any filesystem backed by a block device. Probably same as:

mount type=dev

(presuming the kernel doesn't re-invent the 'dev' filesystem. teehee.
devtmpfs is probably as close as it's going to get.)

If this just sounds like rambling, cat /proc/filesystems to see what I'm
rambling about. :)

> Assuming this syntax is acceptable there are still a lot of open questions
> - do we want to cover remounts and moves with these rules, or do we want
>  a separate flag, or rule to indicate what a move can do

options=remount is _probably_ sufficient for this, though I could probably
be talked into seeing the viewpoint that if there were explicit mount
rules granting options, then it wouldn't make sense to restrict those
options from remount requests.

> - how do we want to cover umount, anything you can mount you can unmount or
>  do we want a separate flag or permission.

Definitely separate flag or permission.

Maybe even something super-clever to provide the equivalent of the 'user'
option in /etc/fstab to allow a process to umount _only the specific
mounts that it mounted_. As it stands, a camera-helper-tool with some
mount rules to allow it to mount USB-attached SD cards would have a rule
like this:

mount type=fat /dev/sd* -> /media/**

and we wouldn't want the camera helper to _also_ be able to unmount the
Sony Reader mounted with identical rules from the Calibre profile. (Of
course, if we add some udev-name-aware labeling rules, this might be less
of an issue.)

umount mounted_by=pid:$$
umount mounted_by=profile:$$   # or some other way to refer to "this profile"?
umount mounted_by=profile:namespace:/path/to/profile ?
umount mounted_by=user:usernames ?



> - what of options like exec/noexec, ro/rw.  Do we want to stick with mount
>  style syntax or an apparmor flags syntax.
>  Eg.
>    ro would map to apparmor r,
>    exec would be apparmor x,   noexec would be the rule not having the x
>    ...

I vote for the 'mount' rules -- admins probably type them all the time.

> - how do we want to express other mount flags.
>  Eg.
>    --bind, --rbind, --make-shared, ...
>
>  Do we specify them in the same way mount does
>     mount --bind /foo/ -> /bar/,
>
>  Do we reuse, the type field when an fstype can't be specified.
>     mount type=bind  /foo/ -> /bar/,
>
>  Do we use an apparmor style permission flag
>     mount /foo/ -> /bar/  (r,x,bind),

I vote for the same syntax as the mount command, if only because these are
difficult enough to understand the first four or five times you use them,
we certainly don't need any additional complications in translating the
mount commands to profile syntax.

How do we handle the unshare(2) system call? I can't find _any_ mediation
points in my kernel source for 'unshare' (not even for capable
CAP_SYS_ADMIN) -- only in do_fork() could I find any security checks.

Thanks John