KUbuntu, root passwords and broken authentication

[Daniel Pittman]

"Scott Mazur" <kubuntulists at littlefish.ca> writes:
> On Sun, 11 Feb 2007 11:15:44 +1100, Daniel Pittman wrote
>
> <snip>
>> > Something someone said in another thread got me thinking.  This was a
>> > kubuntu clean install, on an existing Linux box.  After install the
>> > root password is set, things are checked/updated and finally the
>> > original users /home uid/passwords are returned.  The snippet I'm
>> > remembering is something about only the first user created gets sudo
>> > access during install, and that's the first user to be removed after
>> > returning the original users.
>> 
>> Ah!  So, correct me if I am wrong, but you are:
>> 
>>   A)  Deleting all the normal users created during the install process.
>>   B)  Creating new users with their own UID and group memberships.
>> 
>> During B are you assigning any users to the 'admin' group?
>> 
>> If not then, well, at least we know why those users cannot access 
>> root via sudo.
>> 
>> If you /are/ adding them to the admin group, but sudo is still 
>> failing, then you should report this as a bug.  This is ... 
>> definitely that, since that is absolutely not the way that sudo 
>> should behave -- ever.
>
> Yes, that is exactly what I'm doing.  Adding users to the admin group
> does in fact 'get things working' again.  

Ah.  The other alternative, then, is to install a different /etc/sudoers
file as part of your install process, ensuring that it matches your
expectations WRT admin access. :)

> My bad choice of timing for setting root password before any other
> post-install actions :( Could have saved quite a bit of un-focused
> ranting ;)

You know, last time I had to administer a SuSE Enterprise Linux server I
had quite a few occasions on which I felt exactly the same way. 


>> > Not to say that it does/should work this way, but I would expect (as a
>> > Linux admin with no previous Kubuntu experience), that if I should set
>> > a root password, then kdesu should accept a root password to authorize
>> > admin rights when needed.
>> 
>> Ah.  You "assume."
>> 
>> Linux, as a rule, doesn't have a policy of "magical" changes.

[... running admin software as root ...]

>> > In fact, to the best of my recollection, that IS kdesu's purpose in
>> > the first place?
>> 
>> No.  The purpose of kdesu is to run graphical applications with other
>> privileges than those of the current user.
>> 
>> It provides a graphical password prompt, confirmation that the user
>> wants to take the action, and provides some degree of environmental
>> management to unsure the target application works.
>> 
>> It is *not* designed to "authorize admin rights with the root
>> password;" that is the *mechanism* it uses, not the driving purpose
>> of the tool.
>
> Ah, you "assume" kdesu's purpose is to run applications with other
> privileges.  

Actually, I read the stated purpose in the KDE documentation, but the
effect is probably the same. ;)

> That probably justifies kubuntu's position to substitute the 'su' of
> kdesu with sudo.  kdesu's purpose IS to provide su (root) access when
> needed.

I get the feeling we are going to keep talking past each other here, so
if we continue to disagree I will not continue to pester you about this.

Anyhow, I stand by my statement: the *purpose* of kdesu is to run
software with other privileges.  This typically means running the
graphical software as root.


After the selection of the sudo back-end in favour of the su back-end
kdesu still serves the same purpose but uses an alternate mechanism.

If there were a 'chiark-really', 'calife' or even 'ssh to localhost'
back-end then kdesu would /still/ serve the same purpose.  The mechanism
would be different, possibly radically so, but the purpose the same.

> You don't have to take my word for it, this is evidenced by the fact
> that any user not in the 'admin' group is pestered for password they
> can't possibly provide.

Actually, they are asked to provide a password after requesting an
operation requiring privileges.  

This is traditional Unix model: if you don't have to give away
information, and if that secrecy adds to security, then you should not
give it way.

In this case the secret preserved is that the user lacks the privileges
to perform the requested operation; the security implication is that a
hostile third party with command line access cannot easily probe what
commands the current user /is/ trusted with through sudo.

> Done right, users outside of the admin group wouldn't be offered the
> choice to enter administration mode or at least be allowed to enter an
> alternate user with the password.

I absolutely agree that users without appropriate privileges should not
be given the choice to run privileged software.  There is even, I
believe, a bug filed against this in Launchpad (and, I think, the Debian
BTS) to that very effect.

The choice to continue to prompt is a secure choice, not a user friendly
choice.  This is another choice for which there is no right answer, only
a less wrong one.

>> Also, consider a situation in which a hardware token was proof of access
>> to administrative privileges.  Would you insist that kdesu was doing 
>> the wrong thing because it consulted the token, not the password?
>
> That's exactly the situation where sudo is the appropriate tool.  It's
> also a situation where you wouldn't use kdesu to do it either.  I use
> sudo for just such reasons, which makes me even more leery when the
> desktop starts messing with it.

Hrm.  I think that debate is a tar-pit in which we can get bogged down.
I intended to use that to illustrate my previous point, not open a new
one.

If you do want to discuss that further let me know, but for the sake of
effort on both parts I will leave that choice to you. :)


>> > Whether kdesu should be authorized by a regular user password can be
>> > left to the never ending sudo debate.  But for a regular user not to
>> > be able to use the kdesu mechanism with a root password for it's
>> > intended purpose just doesn't seem right.
>> 
>> It may not be what you expect but, with kdesu configured to use the
>> 'sudo' backend rather than 'su', it will correctly continue to use sudo
>> to obtain elevated privileges.
>
> But only if you're in the 'admin' group.  

Nope.  The user 'root' also has full permissions by default.

Also, of course, anyone else that you grant permissions.  With or, in
fact, without their being prompted for their own password, or for the
root password.

Heck, you could even configure sudo to prompt for (and accept) only the
root password ... and not assign one.  If you really wanted. ;)

> Kubuntu users aren't coming in cold.  Anyone with no prior Linux
> experience could have fired up Ubuntu and been off without a second
> thought.  I'd probably recommend Ubuntu over Kubuntu to a newbie.

At the moment I probably would as well, but not for the reasons
discussed in this exchange.

> Kubuntu users are coming in expecting the KDE experience with KDE
> "assumptions" in tow.  Why bother creating kubuntu otherwise?  

I hesitate to speak for the KUbuntu developers, but I would suggest that
the "KDE" assumptions you are referring to are actually "distribution"
assumptions.  

Any distribution could choose to build KDE with the sudo backend for
kdesu, or to ship without a root password.  

[...]

> Set the 'rootpw' flag was exactly what I wanted.  The actual syntax of
> how to turn it on was harder to find than I would have thought, but
> end result is what I wanted.

I confess: I hate the sudoers manpage marginally more than the rsync
manpage, and both are absolutely full of pain.

I am glad that I was able to help with the 

> Fun as the experiment is though, I'm going to have to put sudo back to
> the install default and work with the user passwords.  Adjusting
> sudo's default behaviour for reasons of the desktop is just bad karma
> in my book.  

You can, I believe, specify the 'rootpw' flag only for some groups or
users in sudoers.  Don't ask me how, but I believe it is possible.

> Points to Kubuntu for creatively modifying KDE to use sudo.  Maybe
> more work on the KDE side of things will improve kdesu authorizing
> options without resorting to hacking in sudo.  

The option is in the upstream source -- KDE officially ship this code.

kdesu is also a very think wrapper over the underlying tool, su or
sudo.  It doesn't actually add much functionality into the mix.

Using sudo allows more flexibility and configuration, including
permitting access to administrative tools with the user password, root
password, based on group or other identity details, or without a
password at all.

On that front I cannot fault Ubuntu at all -- though I can understand
where it may be a surprise when you move from a distribution that
doesn't do things the same way.

> One of the things I like most about Kubuntu is that I find it sticks
> more closely to the standard KDE than other distros.  But on closer
> examination it appears the Kubuntu is no different for all it's
> customizing.

I can't disagree with that statement at all.  Ubuntu make, perhaps, more
changes to their software than others rather than less.  Most of them,
though, are sufficiently unobtrusive and correct that people don't
complain.[1]

[...]

>> > Maybe it's just me, but making things work out of the box just
>> > isn't that big a deal anymore.  All the big distros handle hardware
>> > quite magically these days (to lessor and greater degrees) and
>> > installs have been easy for years.
>> 
>> Yes.  The Wacom thing is, in fact, part of the work that makes that
>> "just happen."
>
> I sure hope your right.  My gut's been right too many times before to
> ignore it now ;)

Well, I hope I am right too. ;)

Anyway, I am glad that we found a solution to your problem and I hope
you understand the why of it a bit better as well.  

Regards,
        Daniel

Footnotes: 
[1]  My favorite is that a large part of the support for SMP
     alternatives in the kernel is thanks to Ubuntu working hard to test
     and promote it.  Simple, correct and very unobtrusive.

-- 
Digital Infrastructure Solutions -- making IT simple, stable and secure
Phone: 0401 155 707        email: contact at digital-infrastructure.com.au
                 http://digital-infrastructure.com.au/