[apparmor] mount rules

[Seth Arnold]

>> - 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.
>>
> sure, you can do that without using the symlink.  You want a short cut to
> say use the path in the symlink.  Is taking a snapshot of that value at
> load time enough, or would you want it to be dynamic to the changing value
> of the symlink?

It ought to be dynamic -- I don't want to have my camera's SD card, my
Sony Reader, my iPod, my BlackBerry, my Top Gear USB Stick, and my
occasional backup-drive all connected at every profile load. :)

>> - 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/....)
>>
> you want extended conditional support, but that isn't going to happen
> in the first pass

Well, if we could use the symlinks in some fashion, I think it could be
done on a first go around. pam_apparmor changes privates first class into
the "pvtfc" profile and officers into the "officers" profile:

profile "pvtfc" {
  mount /dev/disk/by-path/pci-*-scsi-*-usb* -oro,noexec
  ...
}

profile "officers" {
  mount /dev/disk/by-path/pci-*-scsi-*-usb* -orw,noexec
}

If we had a daemon listening for udev events (or inotify events) and a
configuration file like this:

  DISK_USB: /dev/disk/by-path/pci-*-scsi-*-usb*

then the profiles could be written a bit more like this:

profile "pvtfc" {
  mount -label=DISK_USB -oro,noexec
}

profile "officers" {
  mount -label=DISK_USB -orw,noexec
}

>> - I want to confine Calibre to read-write mounts for my Sony Reader.
>>   (/dev/disk/by-id/... or /dev/disk/by-uuid/....)
>>
> I'm not sure I follow you?  I think you are saying you want Calibre to
> only have rw access on one specific mount specified by something in
> /dev/disk/by-uuid/, ie. basically the ereader?

Yes, that's it exactly -- I don't trust Calibre enough to mount anything
else, but I'll trust it with my books. (Honestly, Calibre failed the
automounting big time last time I tried. Hand-mounting devices always
worked better.)

>> - I want my data center operations staff to have privileges to rotate
>>   through a series of specific backup disks. (/dev/disk/by-uuid/...)
>>
> err okay, but I am not sure what this will by you.  A malicious operator
> can change the uuid of a disk

Oh. I forgot. Thanks.

How about drive serial numbers, vendor numbers, and device numbers? Say,
you could allow mounting only Apple devices or Kingston devices, or a
specific USB memory stick with built-in encryption services. (Hardware of
course can report whatever it pleases but this still might be useful.)

> yes, they are convenient, again the question is at what level.  Policy
> compilation, load time, dynamic?
>
> Policy compilation could be just done with a special variable assignment
>
> Load time with kernel vars, with the value set at load
>
> Dynamic kernel vars + daemon triggering on fanotify, or a few other more
> frightening implementations I can think of

Policy compilation and load time are both far too static. Drives come and
go all the time and their scsi name /dev/sd* is next to useless. The
dynamic names are better but troublesome. The more I think about it, the
more I think labeling is the answer here.

(I wish the kernel just gave them persistent names.)

>> deny mount type=nodev
>>
> yes though perhaps not at type= as we may want to use type= and nodev at the
> same time.

Good point.

>>> - 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.
>>
> Or different rule?
>  unmount /blah,

Sure, this sounds like a good idea. I got distracted by my special cases
and forgot simple too. :)

>  Hrmm maybe more like
>
>  unmount label=profile,            # yes I said labeling is a ways a way but
>                                    # but implicit labeling will be closer
>  unmount owner /foo/bar,

Yes, much easier to read.

>> 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.
>>
> basically we don't atm, at least not anymore than we can do with fork

Chalk this up to not looking _everywhere_: unshare_nsproxy_namespaces()
will call capable().

Thanks John