Fedora 12 to remove unprivileged package installation

Posted Nov 20, 2009 8:04 UTC (Fri) by elanthis (guest, #6227)
Parent article: Fedora 12 to remove unprivileged package installation

::rolleyes:: wheel group. That's what it is for. Users with wheel can get all the nice admin-
only features. Let the user GUI have a nice easy "administrator" flag forsetting it for novice
sysadmins. Have it set on the initial user account created by anaconda. Stop reinventing
the wheel (hehe) and creating new weird text file configuration that nobody knows about and
does nothing actually needed that warrants the extra complexity.

Simplicity == godliness.

Fedora 12 to remove unprivileged package installation

Posted Nov 20, 2009 8:20 UTC (Fri) by drag (guest, #31333) [Link] (12 responses)

I don't think that the whole world of group/user/system/application/local/remote policies for a user is allowed or not allowed to do in corporations, home desktops, military, government.. Any and all environments, organizations, and use cases for everything can be managed accurately and effortlessly with that single 'on/off' switch that is 'wheel membership'.

Fedora 12 to remove unprivileged package installation

Posted Nov 20, 2009 8:34 UTC (Fri) by SiB (subscriber, #4048) [Link] (11 responses)

Maybe, a simple on/off switch (wheel group) is much safer in most cases than another bloated mechanism that is difficult to get right and to configure correctly and securely.

Fedora 12 to remove unprivileged package installation

Posted Nov 20, 2009 8:41 UTC (Fri) by jengelh (guest, #33263) [Link]

Indeed. Name SELinux.

Fedora 12 to remove unprivileged package installation

Posted Nov 20, 2009 11:09 UTC (Fri) by drag (guest, #31333) [Link] (9 responses)

Wheel alone is only able to meet 2 use cases. Having a central mechanism like Packagekit means that a user/admin is able to configure their system in a sane manner for a much wider set of requirements.

Hell on my Debian box I have my main user belong to no less then 14 different groups, each of which give different privileges to different aspects of the system. A couple I had to create myself in order to avoid using 'sudo' all the time. (and I can tell you right now that requiring the user to run root code under their account won't fly in the majority of organizations) I can tell you that having a central way to manage user permissions like packagekit is vastly simpler and easier to get right then having to create my own groups, touch a half a dozen different configuration files all over my system and setting up special file system configurations for usbfs and directories in /var in order to avoid using 'sudo'. Half of it was educated guess work.. playing around with different settings until I got things to work properly. I tried to get it right, but I really have no way to properly test it.

Now imagine having to manage a mess of desktops. Dozens or Hundreds or even thousands of desktops. And you have to take into account a many different types of users from different departments with different policies and different requirements. The ability to set 'group policy' is a killer feature for managed desktops. It's to the point now were it's a hard requirement.. unless your OS is able to provide that sort of mechanisms it simply won't be considered.

Even simple single-computer use cases like setting up a guest account or koisk in order to put the system into a secure-enough mode to allow children or untrusted people to use the desktop can be surprisingly difficult to get right, unless your distro has already gone through a lot of effort to pre- configure it for you.

Fedora 12 to remove unprivileged package installation

Posted Nov 20, 2009 11:51 UTC (Fri) by hppnq (guest, #14462) [Link] (8 responses)

Half of it was educated guess work.. playing around with different settings until I got things to work properly. I tried to get it right, but I really have no way to properly test it.

And you seriously prefer that over sudo or configuring it properly? Am I missing something?

The ability to set 'group policy' is a killer feature for managed desktops

In the corporate environments where I work security and functionality are not at all tied to the desktop, which is just a simple display and keyboard so you can login to the applications. On the servers, sudo is hooked up with LDAP to provide specific (groups of) users with specific ways to gain some specific extra privileges and administrators with a way to audit everything.

Simple and effective, because it's standard. Not 100% secure and user friendly, but if something goes wrong (and we can predict this confidently and accurately), we know what went wrong and we can fix it within the SLA.

Fedora 12 to remove unprivileged package installation

Posted Nov 20, 2009 15:14 UTC (Fri) by drag (guest, #31333) [Link] (7 responses)

> And you seriously prefer that over sudo or configuring it properly? Am I missing something?

I usually prefer to at least try to make something better rather then just shrugging and keeping it insecure because it's easier that way.

> In the corporate environments where I work security and functionality are not at all tied to the desktop,

In most places security on desktops is rather important because that is were people get most of their work done and they use desktops to access everything else on the network. This is because they use things like passwords and kerberos tickets as access controls.. if the desktops the people are using is insecure then so is their access to everything else on the network.

They'll use single sign on and things of that nature because the #1 (by a huge margin) threat to security is weak passwords and requiring users to remember multiple passwords and type in passwords all the time is entirely counter productive. It's absolutely critical that they make it as easy and convenient as possible to use secure passwords. So the place the 'ticket' is cache'd in very important as is the places people type their passwords and access other services from; which of course is the desktop.

If all the desktop is nothing more then a overgrown a terminal then that's easy... just deny everything to everybody. But that's not the reality of many places.

None of this is really rocket science and policykit is not the huge bloated monster that people are trying to pretend that it is. Server environments are much simpler and much easier to manage, which is one of the reasons Linux is popular on the servers, but is unpopular on the desktop. "Group Policy" is, indeed, one of the killer features when it comes to something like Active Directory. Policykit can provide one aspect of what people consider 'group policy' and things like Sabayon provide the other half.

Fedora 12 to remove unprivileged package installation

Posted Nov 20, 2009 16:08 UTC (Fri) by clugstj (subscriber, #4020) [Link] (6 responses)

Wow, still trying to justify bad decisions. I haven't seen any use case that couldn't have been much more easily and transparently handled by "sudo". Putting this change in without even having it show up in the release notes deserves all the flaming that has been done - even if it had been a good idea.

Fedora 12 to remove unprivileged package installation

Posted Nov 20, 2009 16:24 UTC (Fri) by drag (guest, #31333) [Link] (5 responses)

Well if your talking about granting passwordless ability to install packages to all local users then Fedora
screwed up on two accounts:

1. Did not put it in the release announcements.

2. Made it default for all local users. It should of only been the default for the initial user.

That was the big mistakes.

The passwordless stuff is actually a good feature though. Asking for the user's password is just
security theater because they have already proven their identity through passwords by being able to
log in before. In addition to that prompting users for their user password offers almost no protection
against attacker dwelling in their user account.

This is a huge misconception that prompting the user for their password multiple times is useful
security. It actually is more likely to make things worse since it encourages bad password policy and
numbs the user against real security concerns. Prompting them for the root password is counter
productive since the whole goal is to eliminate access to root in addition to promoting the same bad
password behaviors and encouraging the user to ignore real security concerns.

The number #1 threat to Linux desktop security is weak passwords. Requiring the user to use the
same passwords multiple times or requiring them to use passwords for regular events is making the
problem worse. Regularly popping up warning dialogs is very bad also. Either they have the rights to
perform the action or they don't.. bugging them over and over again when they have rights to the
action is very 'windows-like' in it's bad behavior.

If you still desire a password for regular desktop events then it should probably be a third 'admin'
password that is not root and is not the user's password. Even though that is still mostly theater it's
probably a good compormize.

Fedora 12 to remove unprivileged package installation

Posted Nov 20, 2009 16:33 UTC (Fri) by clugstj (subscriber, #4020) [Link] (4 responses)

Still haven't seen a use case that would have been difficult/impossible to implement with "sudo". Why the wheel reinvention?

Fedora 12 to remove unprivileged package installation

Posted Nov 20, 2009 16:47 UTC (Fri) by drag (guest, #31333) [Link] (3 responses)

> Still haven't seen a use case that would have been difficult/impossible to implement with "sudo". Why the wheel reinvention?

The use case is "Being able to perform daily desktop activities without granting access to the root account". That's all. Like I said people are trying to make this too complicated or something. I don't know.

The one use case that most people are probably using now and don't give a shit about is the ability to hotplug cameras and USB devices on their desktops. I haven't heard anybody screaming about this for a long time.. not since it was initially introduced and they mistakenly setup the policy for Gnome users to automount any volume and not just removable media.

That's traditionally root-only action that eliminated a big reason for using sudo on the desktop and increased the usability of the Linux desktop in a huge way. No root password prompt and no user password prompt. This goes for cdroms, usb keys, cameras, and other things. Would it make sense to deny the users this feature if they are not members of wheel and go back to requiring them to use sudo if they were members?

The ability to perform that action is configurable through policykit and users can decide the automount policy through configuring apps residing entirely in their user account. Administrators can configure all of this through the policykit/sabayon type stuff combined with other *kit things.

Fedora 12 to remove unprivileged package installation

Posted Nov 20, 2009 19:45 UTC (Fri) by dskoll (subscriber, #1630) [Link] (2 responses)

The use case is "Being able to perform daily desktop activities without granting access to the root account". That's all.

sudo grants restricted access to the root account. So does Policy Kit. The technical details differ (sudo does it in-process with a SUID binary; Policy Kit does it via IPC to a daemon running as root), but you're just quibbling over semantics by claiming that Policy Kit does not grant "access to the root account."

Note that I have no strong preferences for sudo over Policy Kit except for the general observation that very granular and tweakable security facilities are often harder to get right than less granular ones. However, as long as distros do a good job of providing sensible Policy Kit defaults, then Policy Kit is fine. The big issue was that F12's (now reverted) policy was not very sensible.

Fedora 12 to remove unprivileged package installation

Posted Nov 20, 2009 21:18 UTC (Fri) by drag (guest, #31333) [Link] (1 responses)

Yeah. The defaults were not that sensible. Only one user should be administrator and it should of been apparent in the release documentation.

However the Dbus IPC is sockets-based. Nothing exotic like a shared memory scheme or anything like that. It gives users root access via those privileged daemons in the a similar manner that having httpd running as root gives remote users root access over port 80.

So ya any security issues in dbus itself or the dbus libraries that applications use would quite easily lead to a compromise and that is something that distros and developers are going to have to be very careful about. As long as that is audited and user supplied input over dbus is carefully managed then it should reduce the attack vector for attackers seeking local root exploits by quite a bit for typical desktop users (vs traditional linux desktop were open sudo and su access are regularly used features)

Policy Kit vs sudo

Posted Nov 20, 2009 22:07 UTC (Fri) by dskoll (subscriber, #1630) [Link]

However the Dbus IPC is sockets-based. Nothing exotic like a shared memory scheme or anything like that. It gives users root access via those privileged daemons in the a similar manner that having httpd running as root gives remote users root access over port 80.

Except there are two huge differences:

No-one runs httpd as root. It drops privileges immediately after creating the listening socket.
The Policy Kit daemon is explicitly designed to run as root and do root-privileged things. That's its whole purpose, after all!

So it's not the case that all the security lies in dbus. The security lies in dbus and the policy kit daemon and in making sure your policies are correctly implemented. It's the last two (especially the last one) that will cause trouble.

I'm not convinced that a root-privileged daemon that sanitizes its input is any more or less secure than a SUID binary that sanitizes its environment, etc. It seems to me neither approach is inherently more or less secure.

Fedora 12 to remove unprivileged package installation

Posted Nov 20, 2009 8:34 UTC (Fri) by drag (guest, #31333) [Link]

Sorry, that last post came out all retarded and stupid.

What I mean to say is that it is often very necessary to provide a mechanism to have finer grained control over what a user is allowed to do and not allowed to do on a operating system. Depending on the context, depending on specific use cases, environments, and job requirements it is necessary to lock down or open up a system in different ways. Policykit allows administrators and users to implement 'group policies' for the Linux desktop. By providing a centralized and manageable central interface for this sort of thing it allows for much easier management and avoids much of the pitfalls you run into with unmanaged (or unmanageable) desktops.

This sort of thing can be overkill for typical desktop setups, were something like handing over the ability to run arbitrary executions as root willy-nilly (like Ubuntu) is a normal state of affairs, but it would be very nice to eliminate the need for running root for typical, everyday, and/or mundane desktop activities.

So while it may be handy to use 'wheel' to decide what accounts are 'admins' and what are not (thus avoiding making typical users deal with complex policy choices unless they have to). By itself it does not provide the needed controls or mechanisms.