Item1551: Enhancements for Sudo feature
Current State: Proposal Required
Released In: n/a
Target Release: n/a
There are a few enhancements needed to improve the security of the sudo login.
- sudo login should have a configurable session life shorter than the regular user defaults.
- sudo login should be optionally restricted to a list of authorized sudoers
- Requires that sudo should only be allowed by an authenticated user.
- sudo list should be specified in configure
- sudo should ideally elevate privilege without changing user identity.
With the current implementation we could possibly improve usability by shipping an AdminUserLeftBar topic by default that includes a "logout" link along with a clearly visible indicator that the user is logged in as the admin.
(10:37:13 PM) SvenDowideit_: sudo is implemented as a sneaky LoginMgr trick
(10:37:23 PM) SvenDowideit_: where by the sessions can be stacked
(10:37:50 PM) Lynnwood left the room (quit: ).
(10:38:00 PM) SvenDowideit_: the downside is that part of what makes it useful is when the real user mgr doesn't work
(10:38:18 PM) SvenDowideit_: but still - make a feature req
(10:38:43 PM) SvenDowideit_: i recon it might be safer to define the sudoer's list in configure
(10:39:04 PM) SvenDowideit_: so like /etc/sudoers its outside the first compromise list
(10:39:23 PM) SvenDowideit_: and in that case, it will be ~4 lines of code?
(10:39:30 PM) SvenDowideit_: ie, more docco needed than code
(10:39:33 PM) gac410: I've been trying to follow the tweaks in LoginManager, etc. grepping around for admin, sudo, etc.
(10:39:56 PM) SvenDowideit_: iirc the sudo func is all in one place in the login mgr
(10:40:01 PM) gac410: So some cfg variable is list of users, instead of pointer to sudoers topic.
(10:40:05 PM) SvenDowideit_: ya
(10:40:38 PM) gac410: Yes - one place in LoginManager but a few other mentions here and there in other modules.
(10:40:45 PM) SvenDowideit_: :)
(10:42:24 PM) gac410: If LoginManager is not working, user could still access configure to remove list, restoring default operation, or if necessary edit LocalSite.cfg.
(10:42:42 PM) gac410: I figure default should be if no list configured, it works exactly as-is today.
(10:42:50 PM) SvenDowideit_: yup, me too
(10:42:55 PM) ***SvenDowideit_ can leave you to it :P
(10:43:31 PM) gac410: Some future thinking might be to elevate privilege without changing identity. So topic still show *who* changed them
(10:43:52 PM) gac410: But that is getting much more complex I suspect.
(10:44:37 PM) SvenDowideit_: er, yes - ish
(10:45:00 PM) SvenDowideit_: the original proposla was to keep the ID, with a (admin) postfix
(10:45:15 PM) SvenDowideit_: but start the feature req
(10:45:18 PM) gac410: Hack might be to have sudo temporarily add user to AdminGroup maybe in session, but not in topic.
(10:45:24 PM) SvenDowideit_: i ca't entirely recal why i didn't implement it
(10:45:32 PM) SvenDowideit_: exactly
(10:46:20 PM) SvenDowideit_: actually
(10:46:29 PM) gac410: And another request would be a timeout for sudo. I finally added a big red flag to the Admin user WebLeftBar, so I had a hope of remembering that I had sudo'd in (or sudude?)
(10:46:43 PM) SvenDowideit_: you culd probly do that by using the server side session and tweaking the isAdmin method
(10:47:15 PM) SvenDowideit_: timeout - reduce the session timeout by X is sudo?
(10:47:41 PM) gac410: I'll put all this in a feature request and then maybe try my hand at the simpler stuff. We probably need it where I work, and would be good incentive to light a fire on the FW migration.
(10:48:04 PM) SvenDowideit_: yup :)
(10:48:11 PM) SvenDowideit_: thats how i sneak it in too