Re: Local users get to play root?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



(Thanks for a constructive discussion by the way!)

David, added you to CC for a question below:

On Wed, Nov 18, 2009 at 2:31 PM, Chris Adams <cmadams@xxxxxxxxxx> wrote:
>
>> I would agree with that, but it's not trivial.  Are we just scoping in
>> PackageKit here, or also consolehelper @console actions?  Does it
>> imply removing the setuid bit from /bin/ping?
>
> In an ideal world, everything that could grant elevated privilege would
> come without it, and the admin (or spin config files) could easily
> configure it back.

Right.

> That obviously fails for things like /bin/ping, since that uses file
> permissions, and that's part of the RPM (and not configurable).
> However, ping has traditionally been run-able as a non-root user, and it
> is easily spotted with find.

Right; I gave the specific example of ping because it's about the
oldest most "traditional Unix" thing I could think of.

> The number of setuid programs is small
> these days, but several of them are now "helpers" that allow a
> wide-range of other programs access, again with minimal documentation
> (what is pulse/proximity-helper? why is nspluginwrapper/plugin-config
> setuid root?)

Hm, this is off the top of my head, but I think the idea with
nspluginwrapper is that you install the flash-plugin RPM (which has no
idea about nspluginwrapper, and I think upstream is actively hostile
to it actually), then restart firefox (as your user), but the
installed flash plugin needs to be wrapped, so our firefox runs the
setuid script to update the system plugin database.

Not sure about proximity.

Yes, we could clearly use more auditing here.

> I think anything that uses PolicyKit should ship with no elevated
> privileges by default, since it is configurable.

So, that leaves us with the question of how to configure it for
Fedora.   A data point here is that the Fedora polkit package adds two
Unix groups "desktop_user_r" and "desktop_admin_r".  However, it's
unclear to me whether the expectation is that official Fedora
consumables (i.e. desktop installer) would customize PolicyKit using
these.

David, what do you think about having Fedora RPMs have all defaults be
"no"?  And getting this change made upstream?  We discussed this
eariler, you replied here:

http://www.redhat.com/archives/fedora-desktop-list/2007-August/msg00266.html

Do you still advocate "doing this is achieved simply by editing
PolicyKit.conf in the %post of the live cd creator. It's that simple
really." ?

We need to have some "story" for this, otherwise it's really confusing
to everyone, from developers to admins, see e.g.:

http://www.redhat.com/archives/rhl-devel-list/2009-August/msg00578.html

> It would be nice to also get consolehelper, but that is more
> complicated.  I thought that was on the way out (to be replaced by
> PolicyKit), but I see there are still a number of things that use it
> (looking at the F11 desktop I'm on right now).

Yeah, converting system-config- is going to take some time.

> The bigger issue is that much of the policy is not well documented,
> except in the XML files (which are pretty terse).

The individual actions aren't documented well enough?  Or the 1,000
meter view of all of the installed actions on a default desktop?

-- 
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux