[apparmor] mount rules

Sun Dec 18 12:00:00 UTC 2011

On 12/18/2011 02:11 AM, Seth Arnold wrote:
>>> - 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. :)
> 
Well not exactly connected, but accessible.  Again there are ways to make this
dynamic with kernel variables, either through a daemon or in the kernel.

Basically I am looking for incremental ways to provide functionality.  We aren't
going to be able to provide dynamic at this stage, but we should be designing
for it.

>>> - 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
> }
> 
sure but this is dynamic via rewriting and reloading profiles + possibly
some change_profile transitions.  The rules within the profile are static
which is all I even have time to consider.

So patches welcome

>>> - 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.)
> 
hrmm yes could be, but I think providing access to that set of information
isn't going to happen in a first pass.  Not that we shouldn't think about
it

>> 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.
> 
possibly, patches welcome

> (I wish the kernel just gave them persistent names.)
> 
it would be nice

>>> 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().
> 
pfft, again basically we don't, its cap mac_admin.  We control one capability
which we have to grant already for any mount operation, and a couple dozen
other things.  So yeah we can control it at the capable level if you don't
need cap mac_admin