[Utopia] Re: Removable devices and fstab

[David Zeuthen <david fubar dk>]

Hi Nathaniel,

On Sun, 2004-08-29 at 17:39 -0400, Nathaniel McCallum wrote:
> On Sun, 2004-08-29 at 12:29 +0200, Kristof Vansant wrote:
> > > These are handled through fstab, are they not? Just like any unix mount,
> > > you can disable this or limit it to a specific group.
> > yes and fstab-sync from hald edits fstab when a new device is pluged in.
> > So there should be some security options added to fstab-sync that
> > certain devices can only be mounted ro for security reasons. Maybe it is
> > asked to mutch to put the ro option depending on the user group :)
> 
> This brings up a subject that I've been meaning to address for a few
> weeks now.  It is time that we addressed the issue of how we should
> handle removeable devices in a secure manor.
> 
> The current fstab-update situation has a few drawbacks.  The first one
> is that it forces hal to run as root (which it really doesn't need to).

There's already patches flying for this; one of the ideas is that is
should be possible is to run hal as a normal user but make it part of
the disk group so volumes can be probed for UUID etc. 

It needs some work; e.g. callouts (like fstab-sync) probably needs to
run as root or need other capabilities than the hal daemon. Remember;
hal cares about other things than just storage devices; you can run
callouts if network devices, cameras, mp3 players, printers, anything,
appear and disappear. That is intentional.

Thus, some kind of "invoke the callout" helper can be imagined; not
sure, I'm already concerned about performance issues running too many
callouts.

The reason I haven't got around to fixing this yet is just shortage of
time and the fact it requires some thought on how precisely to
architecture it (need to factor things like SELinux into the equation as
well).

> Secondly, it makes it difficult to specify a static mounting policy for
> removeable devices (ie. users should be able to mount cdroms, but not
> usb_key drives).  
> 

Right; some bandaid would be a configuration file fstab-sync; dunno if
that is useful however; perhaps refusing to access storage devices
should be more lowlevel, like in the kernel or something, dunno?

> The major problem is that UNIX treats removeable devices like static
> devices, when in reality, they are somewhat different (though they
> function the same).
> 

Not sure about that; I agree UNIX has a lot of traditional baggage that
is being dragged in, one of them being /etc/fstab listing all available
filesystem which is kind of a nice thing actually (and software depends
on that file being up to date).

> The solution that my company is developing is a policy wrapper around
> mount.   While it is in its infancy, the basic idea is that all static
> system devices (or removable devices you want to limit access to) go in
> fstab.   Removeable devices get handled by the mount wrapper.  On device
> insertion, the mount wrapper is called (from gvm).  The mount wrapper
> then goes through a strict set of policy checks.  Then (if the user has
> access) the device is mounted by its uuid.  If the device is in fstab,
> the mount wrapper drops priviledges and calls mount (mount will fail or
> succeed based on the abilities of the user in fstab).  
> 
> Some advantages of this solution include:
> 1. Providing a consistant mounting point for devices (no matter what
> their /dev name), because they are mounted by their uuid.

You still need some list of available filesystems; the hal daemon got
this list and when using fstab-sync then /etc/fstab will also get
entries.

Thus, any program who depends on /etc/fstab, like GNOME VFS and the KDE
stuff, will see the availability of the filesystem. And then stuff "just
work". Sure, /etc/fstab is not panacea but you can always ask hal about
the UUID, filesystem label; disc type etc. 

Using /etc/fstab will also give the system the ability to select and
maintain policy like mount point location, mount options and so on.

> 2. Adjustable system policy (ie. cdroms are ok, but not usb sticks.
> Thiw would be done through a config file eventually, though not
> currently limited)
> 3. Hal can run as normal user (mount wrapper is setuid, but less code
> runs as root)

Not sure; remember, with SELinux, the super user concept is more or less
going away; programs need some capabilities instead (e.g. program foo
may read/write file bar); it's a lot more fine grained.

> 4. No dynamic updating of fstab 

Why, *exactly*, is this bad? The approach taken by fstab-sync is
practically bullet-proof

 1. it locks /etc/fstab
 2. creates /etc/.fstab.hal.<something>;
 3. checks if /etc/fstab is not updated; if it is, starts over again
 4. renames /etc/.fstab.hal.<something> to /etc/fstab 
    (which is an atomic operation).
 5. drops the lock on /etc/fstab

If you don't update /etc/fstab to match the available filesystems you
may break existing software such as GNOME VFS.

> 5. Consistant way of handling removeable devices
> 

It seems somewhat inconsistent to me that hotpluggable devices and non-
hotpluggable devices gets different treatment here. In fact, why is the
implementation detail that a device is hotpluggable of any significance
here? Why shouldn't this policy also apply to non-hotpluggable drives?

Don't get me wrong; I fully support the idea of restricting access and
doing policy stuff, it's really cool and useful. I think, however, you
may be confusing policy with mechanism.

Best,
David