Mailinglist Archive: opensuse-bugs (19817 mails)

< Previous Next >
[Bug 295341] AUDIT-0: PolicyKit: please add set(g/u)id polkit-* helpers to /etc/permissions.*
  • From: bugzilla_noreply@xxxxxxxxxx
  • Date: Wed, 28 May 2008 08:36:49 -0600 (MDT)
  • Message-id: <20080528143649.3DF3ACC6CD@xxxxxxxxxxxxxxxxxxxxxx>

User zeuthen@xxxxxxxxx added comment

--- Comment #71 from David Zeuthen <zeuthen@xxxxxxxxx> 2008-05-28 08:36:48 MDT
(In reply to comment #69 from Marcus Meissner)
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

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

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

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

"exe" path name checking is not a security feature in any way and should not
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

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.


[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

Configure bugmail:
------- You are receiving this mail because: -------
You are on the CC list for the bug.

< Previous Next >