Bug 177177 - hal policy may corrupt storage media, violate security assumptions
hal policy may corrupt storage media, violate security assumptions
Product: Fedora
Classification: Fedora
Component: hal (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: John (J5) Palmieri
: Security
Depends On:
Blocks: FC5Blocker
  Show dependency treegraph
Reported: 2006-01-06 18:46 EST by Michal Jaegermann
Modified: 2013-03-13 00:49 EDT (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-01-18 16:17:14 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Michal Jaegermann 2006-01-06 18:46:54 EST
Description of problem:

After the last update, and with gnome-volume-manager working again (see
bug #176445) removable media (CD, USB floppy, USB memory stick) do not mount
at all and icons for USB devices do not even show in "Computer" window.
Regular floppy is plain unmountable for non-root accounts.

OTOH a nasty security bug #133584, much discussed and eventually resolved
at that time, rears its ugly head again under a different disguise and loging
even on non-root account quietly populates /media with such crap like
/media/disk, /media/disk-1, and so on.  Some of these new mount points
are even owned by non-root although I cannot really comprehend criteria
by which one or another owner is picked up.

Add to that labeling requirements by current selinux and such unwanted
and highly undesirable automatic mounts are becoming even much bigger headache.

Version-Release number of selected component (if applicable):
Comment 1 Michal Jaegermann 2006-01-11 18:35:14 EST
With hal- fixed disk partitions do not mount automatically
on login, luckily enough, but this seem to be true also for anything else, like
hotplug USB devices or data CDs, so it is hard to tell what really caused that
Comment 2 John (J5) Palmieri 2006-01-11 19:10:41 EST
vfat devices are owned by the user who mounts them.  ext devices take whatever
permissions are on the device itself from what I understand.
Comment 3 Clyde E. Kunkel 2006-01-13 14:48:13 EST
WRT comment #1, fixed disk partitions are still being automatically mounted on
my system, up-to-date with hal- and rawhide.  Is there
something else I need to do to prevent this?
Comment 4 David Zeuthen 2006-01-13 16:07:04 EST
Michal, please explain the attack vector in detail?
Comment 5 David Zeuthen 2006-01-13 16:10:49 EST
Btw, adressing comment #1, it sounds like a bug if we're not automounting
partitions from fixed disks. Comment #3 seems to confirm this.

Responding to comment #3 the answer is simply to disable automounting in the
"Removable Drives and Media" capplet available in System -> Preferences in the
GNOME desktop
Comment 6 Clyde E. Kunkel 2006-01-13 17:17:02 EST
Ahh, yes, that solves the problem of non-removable fixed disk partitions being
mounted.  How can such mounting be a bug as the first part of comment #5
suggests?  I would think only removable hard disk partitions (USB, 1394, PCMCIA,
etc) would be candidates if "Mount removable drives when hot-plugged" is checked
(btw, when only the "Mount and Browse removable media when inserted" are
checked, all non-removable hard drive partitions are still mounted.  I run
selinux=0 on the grub kernel boot command line.
Comment 7 Michal Jaegermann 2006-01-13 17:26:41 EST
An attack vector is very simple.  Assume for the moment that you are
on multiuser machine.  Yes, Linux is used in that way too.  A system
administrator obviously has some good reason not to mount some fixed
disk partitions or otherwise s/he would put these in /etc/fstab.  What
these reasons are you do not have a clue as you cannot second-guess
reasons of a system owner.  Now some user logs in on a desktop and,
surprise, all what was NOT supposed to be mounted now is just fine
accessible, with who knows what kind of information there, to whomever
happened to be logged in.  Moreover some of these mount points are
even owned by that non-root account.  I cannot find a rhyme-or-reason
for the later as my system in the current state does not mount via hal
anything at all.

All of the above was already patiently explained, and resolution reached, at
Please re-read if things are still not clear.  That discussion points also
some other serious flaws in such random mounting.

A suggestion from comment #5 is patently ridiculous.  We are not
talking here about _removable_ media but fixed ones.  It is highly
likely that an owner really wants removable media to be mounted.  In
any case - on my machine these "Mount" boxes in preferences are
checked in and this does not happen for removable media.  It used to
in the past.
Comment 8 David Zeuthen 2006-01-13 19:34:12 EST
Re comment #7 note that the partitions don't get mounted with any particular
options (except for vfat) that e.g. changes whoever owns the files. Thus, the
system owner only needs to ensure that files he wants to keep private are
secured using traditional permission mechanisms. This includes practises such as
synchronizing uid's across systems and so forth. Yes, it's more work.

At this point I'd also like to remind you that only the console user is allowed
to mount these drives. Specifically, the console user may just boot into the
other OS'es used for the other disks and/or disassemble the system and pull out
the disks. He may even boot a live CD and access all data. Physical access to a
box is very hard to guard against.

I'd also like to remind you that if you don't like this you may just uninstall
gnome-mount and use your own hand-coded /etc/fstab entries. That will still work
for some time to come. Oh, you may also tweak the /etc/dbus-1/system.d/hal.conf
file but I'm not in a mood to walk you through this at this point.

Btw, if you didn't know, we're trying to make it easier for the console user to
use his system even it that means more post-installation work for experts like
you. John, shall we close this bug as WONTFIX or NOTABUG? John, we should
probably release note this as well as it's a change from earlier releases.
Comment 9 David Zeuthen 2006-01-13 19:37:25 EST
Btw, there are future plans for gnome-mount to do lock down via gconf mechanisms
but it's not implemented yet and it probably won't make FC5.
Comment 10 Kevin Kofler 2006-01-13 21:43:09 EST
I must say I agree with Michal: 
> Responding to comment #3 the answer is simply to disable automounting in the 
"Removable Drives and Media" capplet available in System -> Preferences in the 
GNOME desktop 
How's a setting for REMOVABLE drives and media affecting NON-REMOVABLE drives 
not a bug? 
> Thus, the system owner only needs to ensure that files he wants to keep    
private are secured using traditional permission mechanisms.    
This doesn't do any good for FAT partitions, which have no permission    
mechanisms at all, nor does it address the issue of ext3/SELinux file system    
> Btw, there are future plans for gnome-mount to do lock down via gconf   
mechanisms but it's not implemented yet and it probably won't make FC5.   
Which means those who don't want it can't even turn the bloody (mis)feature  
off! :-( Not to mention that it should be off by default. (What ever happened 
to "secure by default"? And "safe by default" too, see the issues with SELinux 
file system mangling.) 
/etc/fstab really exists for a reason. Why not simply make it easier to add 
partitions to fstab in firstboot (and ONLY in firstboot)? Firstboot could probe 
for partitions the same way HAL or gnome-mount now does and then allow you to 
check/uncheck the ones to be added to fstab. And if you leave them unchecked, 
they should be left alone. HAL/udev/hotplug are the right tools for removable 
media, but they do not make sense for disks which don't change. 
Comment 11 David Zeuthen 2006-01-14 13:13:55 EST
Thinking a bit more about it (not that I'm changing my mind, 
I still think the console user should be able to mount internal 
disks in the default install), it might be useful for the Mount() 
method in HAL to fail if the system administrator listed the 
partition in /etc/fstab. Hence, if the user lists e.g.

/dev/hdb2 /no/path ext3 defaults 0 0

then attempts to mount /dev/hdb2 via e.g. gnome-mount or 
dbus-send will fail.

This seems to me like a good compromise; it's something that is
easy for system administrators to understand plus it's easy to
express in the release notes.

I will go ahead and implement this - we should be able to get
this in FC5.
Comment 12 Michal Jaegermann 2006-01-14 13:24:16 EST
Re comment #8
> Re comment #7 note that the partitions don't get mounted with any particular
> options (except for vfat) that e.g. changes whoever owns the files. 

Who owns files is only a very small part of the picture.  If you happen to own
a mount point you can, for example, remove and add files.  Also there is a good
chance that you will be able to **read** them.  Various security bugs deal
with a possibility that in some circumstances you have an information leak
because you will be able to read, maybe, some piece of a shared memory and it
may contain something which you should not see.  Here you do not have just
a possible leak but you are opening the whole floodgate to create a river
which can carry the big fleet and curiously enough this does not seem to faze
you at all.  Really hard to comprehend.

https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=133584#c24 unfortunately
still looks like applicable.

> I still think the console user should be able to mount internal disks in the
> default install

Here we go again.  You have no idea what is on that disk.  You have no
idea why it was not mounted in the first place.  And you dare to presume
that you know better.  Well, no, you don't.
Comment 13 David Zeuthen 2006-01-14 13:31:04 EST
> If you happen to own a mount point you can, for
> example, remove and add files.

The mounts created via gnome-mount are created by root; no
existing mount point is ever used for this. 

I expect system administrators to read the release notes 
when FC5 comes out and then they will know what to do in
the unlikely event they don't want console users to access
certain disks on the system.
Comment 14 Michal Jaegermann 2006-01-14 13:44:50 EST
> The mounts created via gnome-mount are created by root; no
> existing mount point is ever used for this.

With this exception that to my great surprise after login as 'michal'
I found one of newly created mounts owned by 'michal'.  The other were
indeed owned by 'root' and all that junk in /media was newly created.

As I wrote, I cannot try to check what is going on as at this moment
all this stuff does not work for me at all for unknown reasons.

Besides this random mess is not that useful after all.  For example
one of partitions should be mounted at 'usr' directory of another file
system to make some sense.  Other things of that sort. Clearly this does
not happen.
Comment 15 John (J5) Palmieri 2006-01-16 11:57:28 EST
Hmm, this is all getting pretty unproductive.  Michal, I have no idea what you
are talking about and can only guess that you have some snapshot of HAL that did
some things that have since been fixed but that other problems have prevented
the whole mount system from working in recent updates.  First before we can even
descuss this we need to work through that problem. So first thing is first, how
did you update you machine.  Is it fully up to date rawhide?

Second, andf this should come after we have you machine working - what are the
partitions you have which pop up.  What file system do they use and how are they
being mounted.  I would just want a list in a spreadsheet like format i.e.

mount      type    options   permissions  should_be_mounted 

Comment 16 Kevin Kofler 2006-01-16 23:50:47 EST
Let's try to make this discussion more concrete: What's the benefit of deciding 
to mount file systems on non-removable disks at runtime rather than at install 
time? Non-removable disks, by their nature, rarely change. So why not make this 
an install-time decision? Because a well-known competing operating system 
assigns drive letters to any disk it can find each time it is booted (which 
creates tons of issues related to drive letters changing and breaking all paths 
which relied on them - your automatically assigned drive numbers have exactly 
the same problem)? 
Comment 17 Michal Jaegermann 2006-01-17 12:38:50 EST
A while ago after some discussions, which clearly only partially were taking
place in bugzilla, some reasonable policy was derived which was summarized in
At that time indeed the talk was mostly in terms of an implementation mechanism
although it was quite obvious that concerns were about effects.

Recent changes patently violate that policy and open the same problems, security
and otherwise and plus some more, as before.  Not mentioning this detail that
if you have more that one such "force mounted" partition then most likely
you are ending up with a nonsensical mess of "separate" file systems.  I really
have no taste to go through the same discussion again about issues which were
apparently closed.

That in this particular moment lots of things on a Gnome desktop are messed up
is not that important and this will likely improve soon.  This only makes hard
to see what are effects, if any, of other modifications.
Comment 18 John (J5) Palmieri 2006-01-17 13:12:11 EST
Then this is not a bug.  The rest should be brought up on the HAL list if you
wish to continue it further.
Comment 19 Alan Cox 2006-01-17 14:03:30 EST
Reopening because its clearly a problem area still.

We have a specific problem if we automatically create mounts for fixed storage
devices. The moment you plug such a box into a fibrechannel setup at a large
business there are going to be nasty suprises. 

Software should fail safe. Thats rule #1, not 'the user should not have to
think', although that is probably rule #2

There are some other problems too. If the device is shared between systems (eg
fibrechannel) and you mount it when it is mounted elsewhere you've just trashed
the file system, even in some cases if the mount is "r/o" because of journal
replay. So I'd rather we fixed this promptly before it leaks into future RHEL
and we smoke some banks storage arrays, and indeed before we trash a system with FC

There is another reason not to mount everything too - the kernel may use
considerable resources on these unused mounts. 

This is all a bit different to USB keys (where multiple mounts are kind of
tricky to achieve and physical presence is implied).

Comment 20 Dr. Gabriella Schmidt 2006-01-17 15:43:01 EST
The owner of the computer should for himself decide wich partitions are visible
after reboot. Sind the last update I get all of them mounted in the media tree
even if they are already noted as user mountable in /etc/fstab by label and
dedicated mountpoints:

LABEL=/1                /                       ext3    defaults        1 1
LABEL=/boot             /boot                   ext3    defaults        1 2
LABEL=/home             /home                   ext3    defaults        1 1
LABEL=/vmware           /vmware                 ext3    noauto,user     1 2
LABEL=/iso              /iso                    ext3    noauto,user     1 2
LABEL=/ix               /iX                     ext3    noauto,user     1 2
LABEL=/free             /unused                 ext3    noauto,user     1 2
LABEL=/                 /mnt/centos4               ext2    noauto        1 1
LABEL=/12                /mnt/fc3               ext2    noauto        1 1
LABEL=/123               /mnt/suse93               ext2    noauto        1 1 

The lables are:
/dev/hda2       /boot
/dev/hda5       /free
/dev/hda7       /
/dev/hda8       /123
/dev/hda10      /1
/dev/hda11      /home
/dev/hdb1       /12
/dev/hdb2       /ix
/dev/hdb3       /iso
/dev/hdb4       /vmware

The resulting table after reboot is
/dev/hda10            15507312   7567320   7139556  52% /
/dev/hda2               101105     64331     31553  68% /boot
/dev/shm                517964         0    517964   0% /dev/shm
/dev/hda11            69346584  57251464   8572472  87% /home
/dev/hda8             15757248   5057632   9899180  34% /media/disk-1
/dev/hda11            69346584  57251464   8572472  87% /media/disk-3
/dev/hda9             15757248     71912  14884900   1% /media/disk-2
/dev/hda7             16516052     77888  15599172   1% /media/disk
/dev/hda5             16516052     77888  15599172   1% /media/disk 

There are even two partitons mounted on the same mountpoint '/media/disk'
After the latest reboot I noticed, that the result is not even reproducable.
I got

/dev/hda10            15507312   7558572   7148304  52% /
/dev/hda2               101105     64331     31553  68% /boot
/dev/shm                517964         0    517964   0% /dev/shm
/dev/hda11            69346584  57191776   8632160  87% /home
/dev/hda11            15757248   8583804   6373008  58% /media/disk-1
/dev/hda7             15757248   8583804   6373008  58% /media/disk-1

This 'feature' really should be OFF per default. 
Comment 21 John (J5) Palmieri 2006-01-18 16:17:14 EST
hal-0.5.6-2 has a temporary fix which sets all fixed disks to be ignored. 
Upstream is working on a more flexible solution. 
Comment 22 Alan Cox 2006-01-19 04:06:56 EST
By way of more info on the resource cost of trying to mount everything rather
than doing it when the admin asks:

Usage depends on file system for per fs cost. Worst cases are things like
reiserfs where a large reiserfs mount takes several megs of ram for its internal
data (and can take several minutes to mount). Ext3 takes a lot less but can take
a minute or so to play back the journal and costs you a thread each instance,
ext2 if clean is quick, if not must be fsck'd first and that can take ages. FAT
(if clean) is pretty fast and low cost. XFS I can't work out as its such complex

There is then a second cost which is the resources allocated to keeping the
block device open. If it is just another partition on an IDE disk its pretty
low, if its the only cause of a disk being active (especially SCSI) it tends to
cost half a MB or so, much more on some controllers. 

Add ~30-60 seconds per physical disk (not fs) if the disk is spun down. For ATA
you can't easily avoid spin up while probing, for scsi you can access some stuff
and status info in this state so may be able to do smarter things.

The automounter (autofs4) is designed to let you avoid a lot of that cost by
deferring actual mounts of file systems but is rather Linux specific in form. It
also doesn't solve the shared access problems with scsi, fc, firewire etc, or
the security one but it may be useful for performance and startup speed by
deferring the actual costs. It could help with the security one as an fs
structure of 

where /media/disk was root/root 0700 would block non root access regardless of
the permissions on the device itself.

Another useful key might be to look at the block device permissions as these are
partly controlled by pam. If the console user owns the device file then I can't
see a case where giving them the an autofs4 entry and mount/access ability is a
problem as they can scribble on the media directly.

Comment 23 John (J5) Palmieri 2006-01-19 10:33:12 EST
These are all useful datapoints.  Thanks Alan.  With HAL doing the mounting
right now we can certantly put some huristics in and even do things like adding
entries to the automounter instead of actually mounting the device.  Great thing
is every system that uses HAL can supply its own mounting application or script
so even though the automounter is linux specific we can add it even if upstream
Comment 24 David Zeuthen 2006-01-21 20:29:10 EST
Just to let know we are working on solving this problem upstream


We might not get the UI in time for FC5 but I definitely think the text-based
configuration will land in time for FC5.

Note You need to log in before you can comment on or make changes to this bug.