Bug 133584
Summary: | fstab-sync by default allows any uid to mount/umount non-default filesystems | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Michal Jaegermann <michal> |
Component: | hal | Assignee: | David Zeuthen <davidz> |
Status: | CLOSED RAWHIDE | QA Contact: | |
Severity: | medium | Docs Contact: | |
Priority: | high | ||
Version: | 3 | CC: | alan, mclasen, mjc, walters |
Target Milestone: | --- | Keywords: | Security |
Target Release: | --- | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2004-10-19 01:42:14 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: | |||
Bug Depends On: | 133941 | ||
Bug Blocks: |
Description
Michal Jaegermann
2004-09-24 22:08:28 UTC
This is not a bug. It's about sane defaults so people don't need to open a shell to access their partitions. Since it appears that you are upset about the defaults you can simply just remove the user and kudzu options and unprivileged users are not able to mount those partitions. It won't help removing the line entirely because then it will be readded on next boot (or next time the haldaemon starts). FYI there will be a /etc/fstab-sync.conf file before test3 such that this behaviour can be customized. E.g. you will be able to specify that fixed media shouldn't automatically be added to the fstab. You will also be able to specify a number of other things. It is likely that the defaults for this configuration file will implement the policy you are claiming is a bug. On the other hand the defaults may be that entries are only added for hotpluggable and removable media. Btw, mounted fixed disks won't be shown on the GNOME desktop in forthcoming release of gnome-vfs2. Sorry this is a bug, its not just a bug its totally insane. Reopening PS: removable media only doesn't work either as a heuristic. A lot of situations lead you to have storage volumes that are not just USB keys as "removable" Fedora's traditional solution to this has been to tie it to the "console user". Can't we just use the "owner" option instead of "user"? > It's about sane defaults so people don't need to open a shell > to access their partitions. I am truly astonished that I have to explain such things here but NONE of these file systems (partitions) is "their" until a sysadmin will say so and will set an access boundaries. You are quietly changing that behind sysadmin back. This detail that on some systems a sysadmin may be their sole user is not relevant here. Alan was very kind calling that "totally insane" (so much for "sane defaults"). I was sorely tempted to use much stronger words. If you are on a quest to save a sysadmin from a shell (shrug!) then write 'system-config-fstab', or whatever, and you can stick into it all menus and eye-candy you desire; but in no circumstances you can usurp vital policy decisions. Responses in comments #1, #2 and #5 show a total lack of understanding of the most elementary issues here. Hello? Wake up! Who brought crack to Red Hat. One way to solve this is to not put the user option on the /etc/fstab entries and the UI could deal with lack of permissions through existing authentication methods (e.g. consolehelper style) - this will even give better security than before wrt. e.g. usb keys. Once we switch to using the "owner" attribute, I don't understand the practical threat here. If someone has physical access to a system (what the owner attribute essentially means, you logged in via local GDM or login), they should have permission to plug in USB devices by default. Actually I haven't tested that GDM doesn't give console user access to logins via XDMCP, but if it does I think that's a bug. We should definitely document this, and make it easy to turn off. Changes like this are what release notes are for. You could just as well argue that our default of giving the console user access to /dev/cdrom is a security hole. Actually looking at it a bit closer, I had thought owner == console privs, but it appears it only means that for the CDROM case because we actually chown the cdrom device to the console user. So it seems we do need a new mount option "console". > Once we switch to using the "owner" attribute, I don't understand the > practical threat here. That would be funny if that would be not about serious matters. Did you ever bother to check what "owner" means in this context and an owner of what? I strongly recommend re-reading of http://www.pbs.org/cringely/pulpit/pulpit20040916.html and pondering a bit over this fragment about an expoxy glue. And you are trying to sneek an instant access to every piece of a disk? Amazing! On comment 10: Michal, as Colin stated in comment 9 he is proposing a new mount option called console. Obviously, this mount option would be like user with the added requirement that the user needs to be at the console. Obviously this is a better default as the console owner could just as well physically nuke the box. Of course, if you now are referring to public terminals I believe it would be a system administration bug to leave partitions with valuable data anyway. Remember, we're talking about the *defaults* and what they should be. One of the goals is actually make people use their computer and storage devices without 1) needing the root password and 2) configuring from here to whoknows. Another one is security. It needs to be balanced, and I'm certainly not proposing to make a insecure system. In fact, I would rather err on the side of making the system more secure. Do you have something constructive to add to this discussion? In case it's not clear Michal, I also consider the "user" mount option a serious security bug. It would for example allow a compromised Apache daemon running as the "apache" user to umount a removable filesystem. But the threat scenarios from an authorized console user are far less clear. If you have an actual situation where this would be a problem, I'm interested to hear of it. > We should definitely document this, and make it easy to turn off.
> Changes like this are what release notes are for.
Eh??? Make it easy to turn that ON and make obvious what kind of
access controls are in force. Defaulting to unsafe settings is
plain crazy. Also think for a fraction of a second about effects
of doing that to a raiserfs file system on an installation booted
with SELinux in an enforcing mode.
BTW - there is something like autofs. With executable maps
automounting of "other" file systems could be even useful as
otherwise this is just an annoying noise in all but the most
trivial situations. What is missing is a way for a non-root user
to unmount automounted volumes other then a timeout. Think about
it and make easy to use that and leave stupid /etc/fstab hacks
alone.
> Defaulting to unsafe settings is plain crazy. I am stating that using console user authentication is "safe". If you disagree, please describe why. > Also think for a fraction of a second about effects > of doing that to a raiserfs file system on an installation booted > with SELinux in an enforcing mode. What specific problem are you referring to? Since reiserfs doesn't support xattrs, it will simply get a generic context like reiserfs_t. It's tunable whether or not the user has access to it. And note that all of the normal Linux permissions apply - SELinux is only in *addition* to those. > I am stating that using console user authentication is "safe". You may be stating whatever you please but you cannot _know_ that as you have no information about what may be on those file systems and why they are present. That is the whole point. Random guesses replacing a basic security is an insanity beyond comprehension. It is not even worth a discussion. People, what is wrong with you? If you are lacking vestiges of imagination I may have on such file system a backup of another machine (the real life situation and far from unique). User id's between the two may, or may not, be uniqe. Now you allow a random login to mount that at will (and a GNOME desktop does that even without asking - which is another story). Hello, anybody home? Examples of that sort are numerous. > Since reiserfs doesn't support xattrs ... I only know that reiserfs indeed doesn't support xattrs and that people with such file systems and installing FC3t2, where selinux is by a default on, were complaining about troubles and errors. It is not likely that this will not happen if you will mount some random file system. But I agree that in this context specifics of reiserfs may be just a distraction. OTOH various unintended consequences when you are springing surprises on a system owner by overriding access policies constitute a clear and present danger. It completely floors me that I have yet to explain such elementary things. > If you are lacking vestiges of imagination I may have on such > file system a backup of another machine (the real life situation > and far from unique). User id's between the two may, or may not, > be uniqe. Sure. Now that we're talking about a more practical situation, let me ask you - do you have any other users that log in with console privileges? But definitely, if you do such a thing, you should certainly be aware of the ability for console users to mount filesystems. I would put all your partitions in /etc/fstab manually with mode=0700,setuid=0,setuid=0. That should prevent any inadvertent access by users. If you didn't do something like this you'd have to be very careful when manually mounting the filesystem, since if you forgot to pass these options and mounted it in /mnt, then *any* user would have access. > I only know that reiserfs indeed doesn't support xattrs and that > people with such file systems and installing FC3t2, where selinux > is by a default on, were complaining about troubles and errors. That's simply a user error for trying to install the entire system onto reiserfs with SELinux enabled. Totally different and unrelated. > It is not likely that this will not happen if you will mount > some random file system. I'm quite sure it will not be a problem. If you have actual evidence to the contrary, I'm interested. > OTOH various unintended consequences when > you are springing surprises on a system owner by overriding > access policies constitute a clear and present danger. It > completely > floors me that I have yet to explain such elementary things. Actually I thought about the issue quite carefully. Your example of a backup with other uids did occur to me. But I doubt there are many systems out there where the system administrator: 1) Follows such a practice of mirroring filesystems, without using something like tar+gpg to encrypt backups 2) Has desynchronized uids across systems 3) Doesn't have the lines in /etc/fstab already with restrictive permisisons 4) Has untrusted users who log in via the console, as opposed to ssh or telnet If you are one of them - well, I sympathize, but you're in the minority. The improvement in functionality for the vast majority of users is worth the trouble for the few. Incidentally, the overall plan is to continue to carefully make the console user more powerful. If you don't want this, I suggest simply removing pam_console from /etc/pam.d/*. Then Fedora instantly reverts back to "traditional" Unix, where you can't use USB or Firewire, can't play CDs, can't configure your network, etc. You have a serious security bug and that is it. No amount of kvetching on your part is going to change that. I am through trying to explain things which should be obvious to beginners. You know, I tried to work with you carefully and patiently to find out whether there would still be a security problem in your situation if we keyed access off console privileges. If you're not going to give me a "yes" or "no" answer, then I just have to assume the problem is solved. We will still keep this bug open until the console mount option is implemented and fstab-sync is changed to use it. Thanks for pointing out the original security issue. Sigh! It is not "mine situation". You got that totally wrong and that is a big part of the problem. If that would be only this that it would be not raising dangerously my blood pressure. Console priviledges really mean that whomever happens to own a console (assuming "owner" here and not "user"), i.e. sits in a front of keyboard, can mount things like CDs and floppies. What you are saying that this is also fine, and apparently even with less restriction than that, for any random file system which happens to be present on disks and was not mounted when a system was coming up. In other words, you _think_ that you know better what policies should apply to some installations about which you cannot have the slightest clue. This is truly insane. This detail if console priviledges are involved or not is irrelevant. I agree that in some situations and with some file systems granting such access may make sense. So fine, make it easy to turn such access on and provide reasonable defaults for its control __when__ such thing is granted. The problem is that right now this is exactly backwards but you are trying to discuss fine points. I would be fine with adding the "console" option for "removable" media
only. But the problem is that "removable" isn't easily defined.
> In other words, you _think_ that you know better what
> policies should apply to some installations about which you cannot
> have the slightest clue. This is truly insane. This detail if
> console priviledges are involved or not is irrelevant.
Actually it *is* relevant. Because if there aren't any, or are very
few cases where this would be an actual problem, then we're fine.
Look - by default, the console user can already reboot the machine,
write to the CDROM device, etc. Mounting removable media is an
obvious logical extension. If you don't like any of this, don't use
pam_console.
> Actually it *is* relevant. Because if there aren't any, You got an example of a situation with a big problem. So that assumption is trivially false. > or are very few cases where this would be an actual problem, If there are "few" then you have a big problem and you have no way of knowing how big this "few" really is. > then we're fine. Are you sure that you work on the right OS? Maybe you would feel better somewhere else? Tell you what? If Alan Cox will say that you are right then I will keep my mouth shut. Go and ask. > You got an example of a situation with a big problem. What big problem? You only provided yourself as an example, but didn't say whether or not you have hostile console users. > If there are "few" then you have a big problem and you have > no way of knowing how big this "few" really is True, but I suspect it's very small (maybe slightly larger than the number of people who have problems with the console user having access to /dev/cdrom). Your implicit confirmation that you don't have any hostile console users only bolsters my conclusion. > Are you sure that you work on the right OS? Maybe you would > feel better somewhere else? I am quite happy to be working on an OS that cuts a sensible line between security and usability. > Tell you what? If Alan Cox will say that you are right then > I will keep my mouth shut. Go and ask. Heh. If Alan can make some arguments against the default console user access, he is free to comment in this bug. I'm especially interested in real-world situations where it's a problem. So far I've only heard a lot of handwaving. I've provided a whole pile of reasons internally. The proposed fstab change is still completely and totally insane. The fact you as you admit "dont understand" half the issues doesn't make them go away. All 'console user' proves is you are the console. It doesn't prove you have any administrative rights to the system, and it doesn't tell you anything about where storage device are. The existing code works because we assume physical access for poweroff is ok (argument that if you physically access the box you can power it off anyway, with an axe if need be). We know the floppy must be within a few inches of the console likewise. "Removable" devices could be anywhere and we have no way of tying them to an owner. So while we can possibly argue that we know a USB connector is "probably" near the console user we have no idea where and what random pieces of removable storage media are. To the kernel "removable media" means hot-pluggable. So your enterprise database will be appearing as "user" in the fstab. I'd hope that strikes you as a bad idea. > The fact you as you admit "dont understand" half the issues doesn't > make them go away. I didn't say that I didn't understand the issues. I said that I didn't understand the practical threat here, and that's *still* true. No one has yet elaborated on an actual real-world situation where this is a problem. > All 'console user' proves is you are the console. It doesn't prove > you have any administrative rights to the system, No, but it does prove that you should be able to use removable media. > "Removable" devices could be anywhere and we have no way of > tying them to an owner. So while we can possibly argue that we > know a USB connector is "probably" near the console user we have > no idea where and what random pieces of removable storage media > are. The exact same argument could be applied to wacky CD-ROM devices that could be on some huge long cable far away from the user. Maybe someone's created a transatlantic IDE cable, so you can play a CD for me from London. But until I hear from someone who actually creates a USB connector that is far away from the computer, *and* has untrusted users with console logins *and* their filesystem permissions would permit access by this console user, you're just handwaving. > To the kernel "removable media" means hot-pluggable. So your > enterprise database will be appearing as "user" in the fstab. I'd > hope that strikes you as a bad idea. First of all, it's not the "user" option. We are discussing the "console" option which is in development. And again, you need untrusted console users, and you need bad filesystem permissions (I'd argue an "enterprise database" that doesn't have that is already seriously flawed, and this is just exposing that flaw). You are also assuming that the "enterprise database" isn't already in /etc/fstab, which seems unlikely to begin with. And as we discussed internally, we could have HAL ignore SAN devices. Actually if you see the internal discussion you'll see that we cannot even tell SAN devices and most of the other arguments you present as "over" are not. Alan Ok the proposed solution appears to be something like this Volumes we will add for mounting by the console user as a default (and nosuid) PC legacy floppy disks (as granted already by pam_console) IDE CD-ROM USB devices except where they hold an existing mount for the system, (eg if /home is on USB we won't give access to it!) The access in question is "console" not "any user", thus you must be physically at the console to do this. At that point you can reasonably remove any USB device, floppy or IDE CD-ROM and take it to another computer. Do you see any holes in that Michal (remembering also that for 'secure' installations where users are forbidden access to media we'd be documenting how system administrators turn it off as we do now with pam_console) ? Some final discussion continuing Another proposal is this one: fstab-sync will add entries for all mountable partitions and drives connected to the system. Only if the entry stems from USB, Firewire, SATA, IDE or x86 legacy floppy and beginning of the volume label doesn't match a FHS2.3 top-level mount point the 'console' option will be added Alan, Marcel: thoughts? In comment #27 Alan asks "Do you see any holes in that Michal". It seems to me that this is more or less equivalent to the situation we have right now although, again, fragments of http://www.pbs.org/cringely/pulpit/pulpit20040916.html give some food for thought. Although competent sysadmins should be able to handle various situations unfortunately not all of them are so competent. On a longer run tools which would allow them easier to handle access configuration to various file systems would be nice. I do not have a big quarrel with arguments raised here and there, like in comment #16, that what we had up to now is somewhat messy in places. But drawing from that a conclusion that therefore it is OK to make a really big mess is something beyond my comprehension. A proposal from comment #28 seems to me way too dangerous. " ... and beginning of the volume label doesn't match". So all of sudden a behaviour depends on a "correct" labelling over which you may not have any control and you do not even know if filesystem in question allow any labels. Sounds to me like a mine-field where things mount or not apparently at random (until you observed a key which is not so readily visible). An absolute security nightmare. As for presumably "insecure" permissions on file systems which are not "magically self-mounted" up to now then they are fairly secure, thank you very much. Only root can mount them so they are rather hard to access by those unauthorized. If root will get compromised then indeed you have problems. No surprises here. After all this long discussion, when it started to look that something begins to click, after updates to hal-0.2.98.cvs20040929-3 and gnome-vfs-1.0.5-21 I am indeed not greeted on a desktop with an icon for every possible file system. BUT ... in /etc/fstab I am "blessed" now with /dev/sda9 /media/scsidisk7 ext3 \ noauto,user,exec,managed 0 0 and so on, and so on, and a simple act of login to a graphic desktop, with no further action on my part, caused 'mount' to show the following definitely unwanted junk: /dev/sda1 on /media/scsidisk13 type ext2 (rw,nosuid,nodev,user=michal) /dev/sda2 on /media/scsidisk12 type ext3 (rw,nosuid,nodev,user=michal) /dev/sda3 on /media/scsidisk11 type ext3 (rw,nosuid,nodev,user=michal) /dev/sda6 on /media/scsidisk10 type ext3 (rw,nosuid,nodev,user=michal) /dev/sda7 on /media/scsidisk9 type ext3 (rw,nosuid,nodev,user=michal) /dev/sda8 on /media/scsidisk8 type ext2 (rw,nosuid,nodev,user=michal) /dev/sda9 on /media/scsidisk7 type ext3 (rw,nosuid,nodev,user=michal) A huuuge improvement (NOT!). Well, some; at least 'nosuid' and 'nodev'. Was all this previous exchange a joke? Who needs their heads examined pronto? Michal, The work discussed isn't yet fully implemented. The patch for 'console' instead of 'user' have been submitted for util-linux for is in yet; I've actually made it a blocker bug (as you should be able to see from this bug); see bug 133941 for details. It is being worked on. Thanks, David Sorry! My mistake. I jumped a gun but sometimes it is hard to know how long to wait. Alrighty, I've uploaded a new hal package, hal-0.4.0-2, into Rawhide as well as an updated util-linux package with a mount(1) that supports the 'pamconsole' option. I've also patched gnome-vfs2 and uploaded that into Rawhide such that it will show entries in /etc/fstab with the pamconsole option (upstream gnome-vfs2 only shows entries with the 'user' option). The new hal package features a man page for fstab-sync with instructions on how to customize how and if entries are added. There's also information on how to totally disable fstab-sync messing with the /etc/fstab file. Also, fstab-sync now puts a comment in the /etc/fstab file pointing the reading to the man page. The defaults are now fstab-sync will add entries for all mountable partitions and drives connected to the system only if the entry stems from USB, Firewire, SATA, IDE or x86 legacy floppy. The 'pamconsole' option will be added. and these are very easy to change. Notably, I've dropped the requirement on not adding entries if the label starts with a FHS2.3 mount point - I don't think that makes any sense really, e.g. users should be able to access the a harddisk from, say, an old server, in an USB2 enclosure. See this screenshot for an example http://people.redhat.com/davidz/hal+gnome-vfs.png The issue Alan raised here > (eg if /home is on USB we won't give access to it!) is in my view kind of moot as a well configured system will already have an entry in the /etc/fstab with LABEL=/boot and fstab-sync won't add an entry in that case. Either way, the defaults are easy to change, so let's see if I should change that back; Alan, please comment. FYI the default naming policy for mount points have also changed (but is totally configurable), I'll send a message to fedora-devel today or tomorrow about this. You might want to check out the mail I've sent to the upstream hal mailing list http://freedesktop.org/pipermail/hal/2004-October/001137.html Marcel: thanks for filing this bug, I'm happy we've now got what I consider a much better solution - I hope you think so to. I'm moving this bug to MODIFIED and awaiting comments before I'm going to close it as RAWHIDE. Thanks, David Opps, Michal, much sorry for calling you Marcel. My bad. My experiments with the current hal-0.4.0-3 seem to indicate that fstab-sync aquired now so much desired sanity. Thanks! There seem to be a problem what what is called above "legacy floppy" and a policy spelled out in a comment #33 does not seem to be applied in that case. It is possible that instead I do not understand something here or maybe some configuration files are messed up a bit. Still sounds like a bug different from this one anyway. Right? > My experiments with the current hal-0.4.0-3 seem to indicate > that fstab-sync aquired now so much desired sanity. Thanks! Thanks for reporting the bug and sorry it took so long to fix. I'm now closing this bug as RAWHIDE. > There seem to be a problem what what is called above "legacy > floppy" and a policy spelled out in a comment #33 does not seem > to be applied in that case. It is possible that instead I do > not understand something here or maybe some configuration files > are messed up a bit. Still sounds like a bug different from > this one anyway. Right? Yeah, this was bug 133777 which I've just closed. |