https://bugzilla.novell.com/show_bug.cgi?id=305525#c2 Alberto Passalacqua changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |alberto.passalacqua@tin.it --- Comment #2 from Alberto Passalacqua 2007-08-28 12:55:47 MST --- I think this is not what we need. It's not the right way to simplify things, because it confuses the user, which acquires administrative rights without actually knowing what he is doing. I recently met a guy on IRC which was confusing root with his user just because Ubuntu thought him that. It's really the wrong way. If you want to make things simpler for desktop users, you might consider what Red Hat did years ago. They implemented an applet to retain the root password for a short time when logged in a desktop environment. Regards, Alberto -- 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.

https://bugzilla.novell.com/show_bug.cgi?id=305525#c4 Benjamin Weber changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |benji.weber@gmail.com --- Comment #4 from Benjamin Weber 2007-08-28 13:06:36 MST --- What you propose is as ubuntu does things, this is significantly less secure. It means - Only one password (the one the user uses all the time) to be compromised by an attacker or script to have complete control over the system. - When combined with sudo's authentication caching it means that the default user has full root priviledges. - With only one password the same password is being used for two different privlege levels, how is the user supposed to know whether an app can damage their system or not. They have to authorise apps running as them, and apps running that can damage the system with the same password. I think this might be more confusing to the user than a separate user account. This is significantly worse than windows where even the Administrator account can't do as much damage as root can, and in new versions of windows authentication priviledges are requested on demand on a per-priviledge basis, not time based. Also you are assuming that even on a desktop there is only one main user. Currently we default to running as a non-privleged user, actions to be performed as root can be authorised using the root password. What is the problem with this? If you mean simply disallowing logging into a desktop environment as root I agree that it would be sensible to disable that. Additionally it would be nice to see applications only running the code that needs to be privileged as a more priviledged user. Currently there are some situations where an entire application must be run as root. This is not good as it means that the GUI may not fit into the user's desktop (if it's a different theme) and The majority of the application does not need the full priviledges. This is an application design issue though, and switching to sudo would not affect this problem, if anything exacerbate it by encouraging people to run applications with full system permissions regularly. In summary things can be made much better, but the ubuntu way just makes things worse both from a security & usability standpoint. -- 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.

https://bugzilla.novell.com/show_bug.cgi?id=305525#c6 Stephan Binner changed: What |Removed |Added ---------------------------------------------------------------------------- Severity|Normal |Enhancement --- Comment #6 from Stephan Binner 2007-08-28 13:34:52 MST --- A different concept is hardly a bug. -- 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.

https://bugzilla.novell.com/show_bug.cgi?id=305525#c8 Marcus Meissner changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |meissner@novell.com Status|NEW |RESOLVED Resolution| |WONTFIX --- Comment #8 from Marcus Meissner 2007-08-28 14:01:20 MST --- If you want to do this yourself, feel free. We give you this choice, see above comments. We will however not make it the default, but pursue different methods of easier usability and configurability. Full root access is not necessary for users. -- 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.

https://bugzilla.novell.com/show_bug.cgi?id=305525#c10 Calvin Gaisford changed: What |Removed |Added ---------------------------------------------------------------------------- Severity|Normal |Enhancement Status|RESOLVED |REOPENED Resolution|WONTFIX | --- Comment #10 from Calvin Gaisford 2007-08-28 14:15:12 MST --- Why was this closed? I'm re-opening it as an enhancement. -- 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.

https://bugzilla.novell.com/show_bug.cgi?id=305525#c13 --- Comment #13 from Benjamin Weber 2007-08-28 14:40:30 MST --- (In reply to comment #9 from JP Rosevear)

(In reply to comment #4 from Benjamin Weber)

...

What you propose is as ubuntu does things, this is significantly less secure. It means

- Only one password (the one the user uses all the time) to be compromised by an attacker or script to have complete control over the system.

Two passwords leads to other problems. See Schneier's piece on Security Usability: http://www.sigpc.net/v5/n1/index.htm

...

- When combined with sudo's authentication caching it means that the default user has full root priviledges.

sudo may not be the way to go. The trend upstream is policykit and consolekit currently where you have more granular privileges. However Mac OS X uses sudo. Sudo can also be configured on a per binary basis.

Indeed, there are other much better solutions to the problem. Configuring sudo on a per-binary basis and policykit permissions don't really solve the problem of requiring authorisation on demand though.

...

- With only one password the same password is being used for two different privlege levels, how is the user supposed to know whether an app can damage their system or not. They have to authorise apps running as them, and apps running that can damage the system with the same password. I think this might be more confusing to the user than a separate user account.

Yes, we shouldn't allow unfettered root access unless re-entering a password (like OS X for things like updates). However making it easier to do things like set the time, configure a printer, manage the network without escalating to root privileges via a password. This is actually important to sysadmins in large rollouts as they want people to be able to do these tasks but they don't want people

These sort of usecases could suit a networkmanager esq approach where The user tools do not need root priviledges. Policies could restrict which users had permission to configure printers etc.

...

This is significantly worse than windows where even the Administrator account can't do as much damage as root can, and in new versions of windows authentication priviledges are requested on demand on a per-priviledge basis, not time based.

Which is widely condemned as a usability nightmare.

Most of the criticisms I've read have been mostly regarding specifics of the user interface design, rather than the concept itself.

...

Also you are assuming that even on a desktop there is only one main user.

Currently we default to running as a non-privleged user, actions to be performed as root can be authorised using the root password. What is the problem with this?

A lot of simple tasks as above become hard to do for an average user who doesn't even know what "root" is.

Quite, and it would be great to solve these. However, giving the user blanket administrative priviledges solves none of the problems. Problem: 1 User wants to edit a protected file 2 user finds it in file manager 3 user clicks on it to edit it 4 user gets permission denied error either then, or worse when they try and save it. Giving them sudo would not solve the problem, they'd still need to know how to auth-up, or worse run the entire file manager as root. Prompting for authentication & authorisation on demand would be much more satisfactory, I don't see an easy way to do this, without modification of the applications though.

...

If you mean simply disallowing logging into a desktop environment as root I agree that it would be sensible to disable that.

Additionally it would be nice to see applications only running the code that needs to be privileged as a more priviledged user. Currently there are some situations where an entire application must be run as root. This is not good as it means that the GUI may not fit into the user's desktop (if it's a different theme) and The majority of the application does not need the full priviledges. This is an application design issue though, and switching to sudo would not affect this problem, if anything exacerbate it by encouraging people to run applications with full system permissions regularly.

I'm not sure how practical that is though. OTOH app armor can add protection for escalated apps.

Yes, apparmour could in future be at the stage where it is interactive and user friendly enough to provide protection for desktop apps. However in this scenaro the apps would have to be already running with full permissions, and then constrained. This means amongst other things no user permissions, so you could write all over someone else's files potentially.

...

In summary things can be made much better, but the ubuntu way just makes things worse both from a security & usability standpoint.

Probably on security, doubtful on usability.

I don't really think this qualifies as a bug. More like a feature.

I would say misfeature. There is a problem, this assumes the solution is sudo. As sudo doesn't solve the problem it is clearly not the solution. -- 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.

https://bugzilla.novell.com/show_bug.cgi?id=305525#c15 Cristian Rodriguez changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |crrodriguez@novell.com --- Comment #15 from Cristian Rodriguez 2007-08-28 15:39:39 MST --- (In reply to comment #0 from Calvin Gaisford)

The root user should not be enabled at all for log in on the Desktop. We should leverage the sudoers file and set up the primary account as an administrator and do away with the root account as far as the user is concerned.

ewww. no, this is a really bad idea, sudo is not the right tool for this job.. this will harm security badly. why people wants to copy exactly the parts of Ubuntu that are plain Non-sense ??? even if policykit and consolekit helps with there are a lot of other things that needs fixing ( most notably Yast) if we go the sudo way, then we can start renaming "/" to "C:\" and writting some nasty viruses.. ;-) -- 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.

https://bugzilla.novell.com/show_bug.cgi?id=305525#c17 --- Comment #17 from Calvin Gaisford 2007-09-06 13:54:10 MST --- What I would like to see it much like the option available in OS X. By default, you cannot login as the root user. In order to perform administrative functions on the box, you have to be designated as an administrative user and you must authenticate to perform whatever it is you are doing. If you are a power user and you want to have the root account enabled, you can go into their account tool and enable it. I'm not advocating any particular way to do this. If sudo is not acceptable by the security team then let's find another way to do this. What I would like to see is the option to setup the Administrative account (root user) removed from the install. -- 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.

https://bugzilla.novell.com/show_bug.cgi?id=305525#c19 --- Comment #19 from Crispin Cowan 2007-09-10 15:28:17 MST --- (In reply to comment #17 from Calvin Gaisford)

What I would like to see it much like the option available in OS X. By default, you cannot login as the root user. In order to perform administrative functions on the box, you have to be designated as an administrative user and you must authenticate to perform whatever it is you are doing. If you are a power user and you want to have the root account enabled, you can go into their account tool and enable it.

I'm not advocating any particular way to do this. If sudo is not acceptable by the security team then let's find another way to do this.

What I would like to see is the option to setup the Administrative account (root user) removed from the install.

You are not removing the root account from the install. You are just making it difficult to access. Making it difficult to access doesn't help either, because there are operations (such as installing new software) that you don't want a non-root account to be able to do. So instead, you have to build some kind of authenticated access to privileged operations. Blocking access to the root account from the desktop does not help. What helps is more intelligent, nuanced access to privilege. That is the goal of PolicyKit. That work is young, but hopefully will help. -- 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.