Bug 401811

After the latest round of updates (I am not sure what may cause
a deeper screwup but metacity and nautilus-sendto look like only
possible, even remotely, candidates)  on my test machine all those
"extra" file systems are not only listed in "Computer" window but
they are are all auto-mounted, shown under Places->Removable Media,
and their icons are dropped on a desktop.

Somebody completely mixed up fixed disks with removable media.

I know that I can set /apps/nautilus/desktop/volumes_visible key
to "false", and at least to reduce a visual clutter, but a side
effect is that when inserting truly removable media a corresponding
icon does not show up on a desktop as well.

Changing that key does _nothing_ for security issues.

I believe the management and mounting is actually HAL. Nautilus is just
providing a pretty user interface and doing its job when the volumes are mounted.

Reassigning. I suspect you can change your system defaults by editing:

/usr/share/PolicyKit/policy/hal-storage.policy

I still wonder how likely is it to protect the file system on non-removable
media from access by not mounting it. File systems are meant to be mounted and
that's what people usually do.

This bug seems invalid; mounting fixed disks require the user to enter the root
password and the user would have to be in an active session on a local console.
It is locked down by PolicyKit. Keep in mind that the user can choose to keep
this authorization forever.

Please reopen if this is not the case.

(If it is the case that the root password is not asked for, then it's indeed a
bug. But I doubt that's the case)

Have a great day! Thanks!

(In reply to comment #6)
> (If it is the case that the root password is not asked for, then it's indeed a
> bug. But I doubt that's the case)

Btw, if you log in as root of course the root password won't be asked. Of
course, this doesn't mean that the right to mount fixed disks is transfered to
the user.

Oh, and btw, since we tell people not to log in as root (there's even a dialog
telling you not to do this) this does not qualify for reopening this bug. Just
don't log in as root; it's bloody insane to do so.

> This bug seems invalid; mounting fixed disks require the user 
> to enter the root password and the user would have to be in
> an active session on a local console.

If the above would be the case I would not bother with writing that
report.  The quoted claim flies in the face of reality I am observing
on my test system.  Nothing is ever asking me about a root
password and disk file systems are mounted on by a non-root user
session automatically or after a click on a icon in "Computer" window.
Why sometimes I am getting automatic mounts and why sometimes I
have to click is beyond my comprehension.  This does not seem to
be consistent. Should I include some desktop screenshots or what?

Here is how a line from /etc/shadow looks on the test system:
root:$1$kCjYnKGS$tvJqenmRSGtUhOcfhg4w6.:13848:0:99999:7:::

Thanks for the hint about
/usr/share/PolicyKit/policy/hal-storage.policy
Right now 'rpm -Vf /usr/share/PolicyKit/policy/hal-storage.policy'
returns silently.  I will see what I can do.  Well, that file says:

    <message>System policy prevents mounting internal media</message>

The only thing is that I do not see that.

(In reply to comment #8)
> > This bug seems invalid; mounting fixed disks require the user 
> > to enter the root password and the user would have to be in
> > an active session on a local console.
> 
> If the above would be the case I would not bother with writing that
> report.  The quoted claim flies in the face of reality I am observing
> on my test system.  Nothing is ever asking me about a root
> password and disk file systems are mounted on by a non-root user
> session automatically or after a click on a icon in "Computer" window.

OK, that sounds like a bug... let's debug then...

 1. What is the output of 

  tree /var/run/PolicyKit /var/lib/PolicyKit

 2. What is the output of (need root)

   cat /var/log/secure* |grep -i polkit

 3. Please attach the output of lshal

Thanks.

Ok, this is how my /etc/fstab for a test installation looks:

#LABEL=/L3              /                       ext3    defaults        1 1
/dev/Vols/Vol03         /                       ext3    defaults        1 1
LABEL=/boot_b0          /boot                   ext2    defaults        1 2
devpts                  /dev/pts                devpts  gid=5,mode=620  0 0
tmpfs                   /dev/shm                tmpfs   defaults        0 0
proc                    /proc                   proc    defaults        0 0
sysfs                   /sys                    sysfs   defaults        0 0
LABEL=SWAP-sda          swap                    swap    defaults        0 0
LABEL=SWAP-sdb          swap                    swap    defaults        0 0

And these are results of 'ls -d /media/*' immediately after I logged into
a gnome session as 'michal':

/media/_  /media/_1  /media/_2  /media/_boot

As you can see none of file systems auto-monted under /media/
belongs to that installation.  I can mount more fixed disks file
systems by clicking at other file system icons in a "Computer" window.

'w -h' shows

michal   tty7     :0               20:03    5:54   2.17s  0.16s /usr/bin/gnome-
root     pts/0    some.remote      20:16    0.00s  0.00s  0.00s w -h

with root looged now by ssh and watching what happens

An output of 'tree /var/run/PolicyKit /var/lib/PolicyKit'
/var/run/PolicyKit
/var/lib/PolicyKit
`-- uid400-org.freedesktop.hal.storage.mount-fixed.grant

There is one file of a zero length.  400 is uid of user 'michal'.

An output of
Nov 27 13:25:01 dyna0 polkit-grant-helper[2982]: granted use of
action='org.freedesktop.hal.storage.mount-fixed' to uid 400 [auth='root']
Nov 14 20:43:36 dyna0 useradd[4669]: new group: name=polkituser, GID=87
Nov 14 20:43:36 dyna0 useradd[4669]: new user: name=polkituser, UID=87, GID=87,
home=/, shell=/sbin/nologin

What produced that "granted" I have not the slightest idea.

An output of lshal in the next attachment.

Created attachment 274621 [details]
an output from lshal on the test machine

(In reply to comment #11)
> An output of 'tree /var/run/PolicyKit /var/lib/PolicyKit'
> /var/run/PolicyKit
> /var/lib/PolicyKit
> `-- uid400-org.freedesktop.hal.storage.mount-fixed.grant
> 
> There is one file of a zero length.  400 is uid of user 'michal'.
> 
> An output of
> Nov 27 13:25:01 dyna0 polkit-grant-helper[2982]: granted use of
> action='org.freedesktop.hal.storage.mount-fixed' to uid 400 [auth='root']
> Nov 14 20:43:36 dyna0 useradd[4669]: new group: name=polkituser, GID=87
> Nov 14 20:43:36 dyna0 useradd[4669]: new user: name=polkituser, UID=87, GID=87,
> home=/, shell=/sbin/nologin
> 
> What produced that "granted" I have not the slightest idea.

This is why. The logs indicate that you (or someone knowing the root password
using your account without your knowledge) indeed authenticated as root to gain
the authorization for org.freedesktop.hal.storage.mount-fixed. According to the
logs this incident happened at Nov 27 13:25:01.

I can't remember the exact semantics when the root password is blank; I think
what happens is that the authentication dialog never shows and the authorization
is granted. At least that's what is supposed to happen. Maybe that's why you
can't remember it; e.g. the root password was blank?

Please note that the org.freedesktop.hal.storage.mount-fixed is set up by
default such that the authorization can be retained indefinitely. In fact, the
auth dialog defaults to checking that option:

 http://hal.freedesktop.org/docs/PolicyKit-gnome/auth-retain-always.png

Try running 'polkit-grant --delete michal' as root and the authorization will be
deleted and user 'michal' will not be able to mount fixed drives anymore. Does
that work?

Either way, based on the above, I'm not sure this is a bug... OK to close it?

Looking at your questions and my answers - some time ago I was
testing a behaviour of a remote access with a root password empty.
I will not tell now a precise timeline but I do not seem to recall
anything funny with filesystems auto-mounted then.  I likely noticed
that later.

Could be that bugs really are
  - some capabilities are granted too hasty
  - they are not revoked when the situation changed

If that is the case then I still think that these are serious
security bugs but they are not as serious as they looked to me
in the first place.

> The logs indicate that you (or someone knowing the root password

This is a test system.  There is me on it and root and system accounts.

> I can't remember the exact semantics when the root password is blank;

That you can't remember, and that this is not documented in a
prominent place, is indeed a big problem.  Springing on somebody
nasty side-effects in access grants is bound to create security issues.

> Please note that the org.freedesktop.hal.storage.mount-fixed is set
> up by default such that the authorization can be retained indefinitely.

Oh!  How nice!  Especially that nothing ever asked me if I agree
to such setup or told me how to avoid such thing.  Keeping authorization
indefinitely, quietly and regardless of changes in a situation
which allowed such grant, looks to me like a HUGE design BUG with
obvious security ramifications.

It's an interesting philosophical question what should happen when there is no
root password set. The historical behavior of consolehelper is the same fwiw: no
auth dialog is ever shown. One reason this is useful is live images and virtual
appliances; here it's useful not to bug the user with such dialogs. 

Keep in mind that authentication dialogs are mostly always a cop out because the
OS vendor / system administrator didn't optimize the system for the intended
users. They slow down users and most users don't understand the and just click
through. In the perfect world, the users will have the authorizations they need
and that's it. Unfortunately this dream is hard to achieve in a general purpose
OS that people use for both laptops and servers. The notion of spins in Fedora
can alleviate this; for example for the desktop live CD we'll probably default
to mounting partitions from fixed drives without asking for the root password.
With PolicyKit 0.7 such behavior can be tweaked from both the command line and a
GTK+ app:

 http://people.freedesktop.org/~david/polkitg-auth-1.png
 http://people.freedesktop.org/~david/polkitg-auth-2.png
 http://people.freedesktop.org/~david/polkitg-auth-3.png

Maybe one thing to do when a user has no password is to only grant the
authorization for the desktop session in question; e.g. on your next login the
authorization won't apply. I might add that to PolicyKit 0.7 or 0.8 (0.7 will
hit rawhide very soon). I'll try to remember to follow up on this bug when it's in.

Anyway, I think the bug in the first place is that you had the root password
blank. Either way, I don't see any 'serious security bugs' here; the system is
working according to spec. So I'm closing this bug. Thanks.

(In reply to comment #15)
> That you can't remember, and that this is not documented in a
> prominent place, is indeed a big problem.  Springing on somebody
> nasty side-effects in access grants is bound to create security issues.

Please. The reason I can't tell for sure is that I don't know your PAM setup.
I'm pretty sure the default PAM setup never initiates a conversation if the
password is blank.

> > Please note that the org.freedesktop.hal.storage.mount-fixed is set
> > up by default such that the authorization can be retained indefinitely.
> 
> Oh!  How nice!  Especially that nothing ever asked me if I agree
> to such setup or told me how to avoid such thing.  Keeping authorization
> indefinitely, quietly and regardless of changes in a situation
> which allowed such grant, looks to me like a HUGE design BUG with
> obvious security ramifications.

FFS. You left the root password blank. Do you even _realize_ what unprivileged
apps can do in that case?

> One reason this is useful is live images and virtual appliances;

Agreed.  Still the bug is that if some access was granted due
to special conditions, like an empty root password, then it is
not made dependent on that.  Such dependency would terminate that
automatically when that circumstance changed.

I am still left scratching my head how an administrator should
revoke such thing.  Does removing a file in /var/run/PolicyKit/
is good enough?  Some other magic?  Is this documented somewhere
on the system with clear warnings?  Pictures of some utilities
is not good enough.  One has no idea what this can do and where.

Springing quietly on an administrator surprises of that sort
is an obvious recipe for a security screwup somewhere.  With
a number of systems around you may take it for granted that this
will happen on some production system and not on a test setup.

BTW - the only filesystems auto-mouted, or which were showing up
in "Computer" window were those directly on disk partitions.
Other on LVM volumes, with labels or not, were not there.
Why this distinction?

> You left the root password blank. Do you even _realize_ what
> unprivileged apps can do in that case?

Yes.  I do.  Apparently much better than you ever did.

Do you realize that there could be circumstances where no root
password could be a valid configuration?  Did you notice that
after that root password changed?

(In reply to comment #18)
> > One reason this is useful is live images and virtual appliances;
> 
> Agreed.  Still the bug is that if some access was granted due
> to special conditions, like an empty root password, then it is
> not made dependent on that.  Such dependency would terminate that
> automatically when that circumstance changed.

As mentioned in comment 16 I've added that feature; it will land in Rawhide when
PolicyKit 0.7 lands.

http://gitweb.freedesktop.org/?p=PolicyKit.git;a=commitdiff;h=fb84bb8bd159d2c96402f448a516ff3d1db0fbd3

In a nutshell, when a) there's no PAM conversation involved; and b) the
authorization would be valid indefinitely; then we limit the scope of the
authorization to the desktop session.

> I am still left scratching my head how an administrator should
> revoke such thing.  Does removing a file in /var/run/PolicyKit/
> is good enough?  Some other magic?  Is this documented somewhere
> on the system with clear warnings?  Pictures of some utilities
> is not good enough.  One has no idea what this can do and where.

Try 'man polkit-grant'. For F8 and PK 0.6 it's not very fine-grained; you can
only delete all or nothing via that tool (however just deleting the files in
/var/{lib,run}/PolicyKit works too). For PK 0.7 and F9, it's much better

http://hal.freedesktop.org/docs/PolicyKit/polkit-auth.1.html

plus there will be a GUI tool (screenshots mentioned in comment 16) too.

> Springing quietly on an administrator surprises of that sort
> is an obvious recipe for a security screwup somewhere.  With
> a number of systems around you may take it for granted that this
> will happen on some production system and not on a test setup.

I'm not sure it's as bad as you claim; for example we do log stuff like this to
/var/log/secure. But, sure, I've added the fix for F9 so it's harder for people
to shoot themselves in the foot.

> BTW - the only filesystems auto-mouted, or which were showing up
> in "Computer" window were those directly on disk partitions.
> Other on LVM volumes, with labels or not, were not there.
> Why this distinction?

Basically because the desktop tools (nautilus, g-v-m, gnome-mount) and HAL don't
really work well with LVM because LVM is a bit more complex. There's just a lot
of corner cases involved doing this right; one of them is assembly of the LV
from the PV's etc. etc. For F10 I hope to solve this nicely so there's automount
of LVM and RAID when you plug in e.g. a disk tower via eSATA or whatever.

Regardless of everything else, and accepting all these explanations
above, one clear security bug still remains.  Even in the world where one
is not doing anything "unexpected" hal is leaking, via "Computer" window,
an information about a system which otherwise is not available to
non-root users.  At least that is the case for a default configuration.
It appears that if you want to guard against that then you should
use LVM.  At least for now. :-)

If somebody wants to pursue that subject then be my guest.  I have
enough and I am out of here.