https://bugzilla.novell.com/show_bug.cgi?id=295341
User zeuthen@gmail.com added comment
https://bugzilla.novell.com/show_bug.cgi?id=295341#c71
--- Comment #71 from David Zeuthen
1. It is not clear why mount.fixed permissions are required at all, Kay nor anyone else has not answered our several queries regarding this.
This question needs to be answered first, all others depend on that one.
HAL allows you to mount "fixed" (e.g. partitions from non-hotpluggable disks that doesn't support removable media => typically windows, os x partitions) but that requires another authorization if it was non-fixed (e.g. partitions from hotpluggable OR removable disks). So in that case you get asked for the root password to do this. You can retain this authorization so you won't get asked for a password again. Which is the _sensible_ thing to do if you realize that users typing in passwords and getting interrupted by password dialogs is _bad_ "security". [1] Anyway, distributions and/or sites can tweak this behaviour; for example # polkit-action --set-defaults-active org.freedesktop.hal.storage.mount-fixed auth_admin will change the defaults such that the authorization can't be retained. All this works fine. (And this is much more preferable than the rather useless patch you guys are shipping to PolicyKit-gnome (I found this out when I was meeting with Kay a few weeks ago) that just deselects the "retain authorization" checkbox... all that patch does is just to make the user type in his password again and again... Btw, I'd appreciate if you guys sent patches like that upstream so I don't have to explain why it's non-sense in a downstream bugzilla entry.)
Ability to mount fixed disks/partitions is definitely a critical security risk.
Depends on what OS you're shipping. If it's for a laptop this is definitely not true; clearly users wants to access files from the other OS on the laptop. However, if it's for a server it's definitely true. See the bug linked in [1] for more thoughts about this.
2. There is apparently no code in FACTORY exercising this for us to even look at.
Maybe you guys are still shipping a patch to HAL that hides all fixed disks (e.g. setting volume.ignore); I don't know. Either way, it works fine in Fedora and Ubuntu; I can happily mount my Windows and OS X partitions.
3. The helper binary itself is fine in a self contained way.
4. The use of "exe" name checking does not help, if the user has control over this executable via LD_PRELOAD, PTRACE or other means. He can just inject any code into this binary. Davids comment regarding "secure" binary likely means that the user binary itself needs setgid/setuid permissions.
Yes, that's what I meant with "secure" binary; it's shorter to write "secure binary" than go through a (non-exhaustive) list of what attack vectors to cover.
"exe" path name checking is not a security feature in any way and should not be handled as such, as the source code even says.
It's not really a security feature, I don't know where you got that idea from. Clearly, this bit should tell you otherwise http://hal.freedesktop.org/docs/PolicyKit/polkit-polkit-sysdeps.html#polkit-... However it _is_ useful for binaries that can be securely locked down. For the record, it's exactly the same approach that AppArmor and SELinux takes; e.g. in SELinux you can tag a process as running in a security context (through xattrs of the binary) and that way it can do more syscalls than other processes / get more privileges. Ditto with AppArmor, it just happens to be path-based. And surely such processes are just as vulnerable to code injection as other programs.. except that glibc secure mode and other bits kick in so you can't ptrace the process nor use LD_PRELOAD etc. But that still leaves plenty other attack vectors (e.g. PYTHONPATH, GTK_MODULES etc.). The "only" difference here is that PolicyKit is purely application based; the mechanism is exactly the same: you look at characteristics of the process wanting to access something to make a decision. So if you're saying "omg, that exe thing is evil", I think you should examine how AppArmor works. Hope this clarifies. David [1] : the whole point of PolicyKit is absolutely not the password dialogs; users should simply have the authorizations they need to do their work / use their system. They should certainly *not* be interrupted by password dialogs. I'd go as far as saying that passwords dialog are evil and a disease. It's, for the most cases, bad security (trusted path is the exception). Anyway, there's a slightly longer and more detailed rant about this here http://bugzilla.gnome.org/show_bug.cgi?id=531609#c9 -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.