Feature Proposal: Enhancements to sudo login to improve security

Requirements

Currently once the common sudo password is known, anyone, including guest users can become administrator. sudo needs to be restricted to a list of authorized users. Priority ratings are CDot's, reflecting what he thinks are the priorities of his potential client for this work.

Requirement	CDot Priority
1	Optional list of users permitted to access the sudo login	high
2	sudo should elevate privilege of the user without hiding the user's identity	high
3	Maintain the page context as it was when the user sudo'd	high
4	Must cleanly integrate with LDAP	high
5	Disable sudo access direct from WikiGuest (require a logged-in user)	medium
6	Protect the configure password	medium
7	Shorter session timeout for sudo sessions	low
8	Simple route to elevating "installing user" to admin	low

Description and Documentation

Described also in Tasks.Item1551 Add a sudoers list to LocalSite.cfg Also add a sudo timeout. sudo should also preserve identity of original user in all topic revisions performed as administrator.

Examples

• $Foswiki::cfg{AdminSudoUsers} = 'FredUser,JoeAdmin';
  • Optional list of users permitted to access the sudo login
  • If not configured, sudo login should work as currently implemented
• $Foswiki::cfg{AdminSudoExpireAfter} = 1200;
  • Shorter session timeout for sudo sessions.
  • If not configured, should default to normal session timeout
• $Foswiki::cfg{AdminSudoPreserveIdentity} = 1;
  • If configured, sudo should elevate privilege of the user without hiding the user's identity.
  • Topics modified while running as sudo should record original user in revision history.

Impact

If not configured, there should be no impact to current installations. If configured, it should improve the security of the sudo facility.

WhatDoesItAffect:

%WHATDOESITAFFECT%

edit

Implementation

-- Contributors: GeorgeClark - 02 May 2009

Discussion

I like the idea - this would finish off the sudo work that i began in twiki 4.0.something.

-- SvenDowideit - 06 Mar 2010

Because with sudo the admin can be anyone, the simple highlighting trick in AdminUserLeftBar won't work anymore.

We need a proper fix to visually notify you are in sudo state. This should become a required template element, across all templates (view, edit, etc).

-- ArthurClemens - 29 Nov 2011

It says above: "If not configured, there should be no impact to current installations. If configured, it should improve the security of the sudo facility."

Does that mean default installation would not use the improved security feature, so it won't break existing installations? I'd prefer increased security of the default shipment if possible.

-- IngoKappler - 30 Nov 2011

We can probably set reasonable defaults for new sites that are more secure. A sudoers list is probably unreasonable to default. Actually it probably ought to be a Group instead of a list in configure. We don't want to add more hurdles for the new admin, so until the Group is created, it should be open to anyone knowing the password. Otherwise, there is the catch-22 of how does the new admin add the first member.

Expiration could reasonably default. Preserve identity we need to think through a bit more. There was an IRC discussion where a user objected to preserving identity, and instead wanted a per-sudo-user "admin" identity, so it's possible to differentiate changes made under admin authority from the user's normal authority. Maybe when JoeUser becomes the sudo admin, they become JoeUser(admin) or something similar. Need to work out how this fits with the mappers.

-- GeorgeClark - 30 Nov 2011

On behalf of a client, I did an experiment to enable sudo without losing the current user id. It was a small code change (though it took a while to work out what to change). So now I'm looking to gather other requirements for this. Here are some more not reflected above:

1. Disable sudo access direct from WikiGuest (require a logged-in user)
   • Sven: can we do this using the {AdminSudoUsers} setting George proposes (which I'd like to allow to be groups for self management too)
   • CDot: that's what I was expecting, yes
2. Clearly identify changes made by the sudoed version of a user (e.g. not GeorgeClark but SudoGeorgeClark)
   • Sven: I'd prefer that we make Sudo to 'group' - initially just SudoAdminGroup, so the cuid might be something like SudoAdmin(mapping_SvenDowideit). This would allow the TOPICINFO and logs etc to contain the added info, and then for Foswiki::User to pass on only the non-sudo cuid to whatever mapper is configured.
   • CDot: the more I think about this, the more I fail to understand your argument for this extra layer of complexity. Given that the core code ensures that an admin can do anything, what is the point of a SudoAdminGroup?
3. Protect the configure password
   • Sven: do you mean the additional requirement I add below? CDot: yes
4. Don't dump the sudoer into Main (as happens at the moment)
   • bug - kill it

-- CrawfordCurrie - 25 Jan 2012

I've added a little inline to Crawfords requirements.

George - I don't think {AdminSudoPreserveIdentity} is a good idea, as it means users will have no way to understand or track how the topic permissions were disobeyed, leading to future distrust of the ACLs. For this reason, I proposed the SudoAdmin(mapping_SvenDowideit) style cuid (which rendering can annotate to ensure less loss of trust than we have today)

additional requirement (protect admin pwd)

Rather than sudo-ers needing to know the configure admin password (its really an su impl at the moment), require the user to re-enter their own password when sudo-ing - just like unix sudo.

however - it would be good not to remove the other existing (but hidden by UI) functionality, where anyone can come to anyone else's logged in foswiki session and su(do) to their account, by entering their username and password (and then pop their user off the stack to go back to the previous).

-- SvenDowideit - 26 Jan 2012

Whoa, this is getting complicated. I am probably not going to implement all the features described here, so I've refactored the requirements to the top, and set a priority on each requirement.

-- CrawfordCurrie - 26 Jan 2012

Maybe the term should be worded preserve accountability instead of preserve identity. Keeping the original ID vs. a mapped sudo_ID is just an implementation details. I think it's just important to know who made a change.

In thinking about this a bit more, we need to be sure we don't create a catch-22 in the implementation. IIRC one of the original purposes of sudo was so the first admin could be added to the AdminGroup.

I noticed that I'm listed as having raised a concern. Not sure why I did that, but it's removed.

-- GeorgeClark - 26 Jan 2012

Sudo was originally introduced to enable the installer to add himself to the AdminUser group.

That is also a requirement that needs to work.

I never liked this way to becomes initial admin. It is too geeky IMHO but it is the current way we have.

I have always wanted the registration of first user and adding this user to the AdminGroup to be something the configure script should guide the first time installer through. But unless someone feels like spending time on something like this, sudo is the way. And then we cannot default sudo restrictions in a way so we forget the need for the initial user to elevate himself to admin.

-- KennethLavrsen - 26 Jan 2012

I don't think that was Sven's sole intention with sudo, but you are right that it is an important requirement. I have tried to reflect it in the requirements (bearing in mind always that the priorities there are my priorities, and I am trying to reflect what I think are the priorities of my potential client for this work). I think we need however to express it independent of the AdminGroup. There are currently two "I am admin" mechanisms in the code, one of which is AdminGroup and the other is the internal cache of Admin status. My personal view is this (implementation, not requirement, so not discussed above)

1. The sudoers list should be defined by $Foswiki::cfg{SuperAdminGroup} (i.e. AdminGroup)
2. Otherwise, AdminGroup is just like any other group w.r.t permissions
3. If (and only if) AdminGroup is empty or missing, WikiGuest should be able to "sudo".

This addresses the need for the first user to be able to sudo, because they do it from WikiGuest. This allows them to create a set of initial users and lock down AdminGroup when they have enough knowledge/experience. It also allows an admin to do a certain number of operations without sudo'ing (giving themselves blanket access) because they are in AdminGroup.

This isn't this deal solution, but it feels to me like a good way to move ahead from where we are.

-- CrawfordCurrie - 27 Jan 2012

Recent experience has shown that there is a simple and effective way to elevate selected users to admin status.

• First, define an admin as "anyone with CHANGE access to the AdminGroup" (REQ1, REQ5)
• Second, add a button that is only shown to these people (REQ5, REQ6), called something like "elevate me to admin" (REQ2, REQ3)
• The button calls manage?addUserToGroup to add the current user to AdminGroup
• The reverse can be used to remove the user
• Some template fluff can be used to highlight when the current user is an admin
• Does not work with groups stored in LDAP, but does work with Foswiki groups with LDAP logins (REQ4).

This approach addresses requirements 1, 2, 3, 4, 5, and 6, leaving only

7	Shorter session timeout for sudo sessions	low
8	Simple route to elevating "installing user" to admin	low

I am therefore rejecting this proposal.

-- CrawfordCurrie - 17 Feb 2012

Not quite. I think part of my original concern got edited out during the history of the topic.

• $Foswiki::cfg{AdminSudoUsers} = 'FredUser,JoeAdmin';
  • Optional list of users permitted to access the sudo login
  • If not configured, sudo login should work as currently implemented

I still think it's an issue if someone can figure out, guess, social engineer or in some way recover the admin password, they can quietly sudo or log in as AdminUser.

In light of the above solution, maybe this can be reduced to an option, settable in configure, to disable sudo login. And a checker to warn if it's enabled.

-- GeorgeClark - 17 Feb 2012