[Bug 12576] popt aliases allow users to bypass sudo argument restrictions

[samba-bugs at samba.org]

https://bugzilla.samba.org/show_bug.cgi?id=12576

--- Comment #5 from Karl O. Pinc <kop at meme.com> ---
On Sun, 12 Feb 2017 02:18:35 +0000
samba-bugs at samba.org wrote:

> https://bugzilla.samba.org/show_bug.cgi?id=12576
> 
> --- Comment #4 from Paul Donohue <samba-bugs at PaulSD.com> ---
> That's an interesting solution, but it doesn't really work well for
> my use case.  I would like my users to be able to maintain their own
> SSH keys (this solution would require me to manage users' SSH keys in
> /root/.ssh/authorized_keys), and I don't particularly want to set
> "PermitRootLogin yes" in /etc/ssh/sshd_config.  I also already have
> scripts to manage sudo permissions, and I would have to make some
> significant changes to support centrally managing authorized_keys.

You don't have to set "PermitRootLogin yes".  You can set
"PermitRootLogin forced-commands-only".  Far more secure.

Yes, you probably would need a script, or something, that takes a ssh
key and somehow modifies /root/.ssh/authorized_keys.  

One secure way to do this is to have a script (or any
other interface) that drops a file containing the key 
(and other requisite information) into a directory
that is watched with, e.g., incron.  incron can then run a script
that parses the file, pulls out the requisite information, and
has the permissions to modify /root/.ssh/authorized_keys.
(And then cleans up by deleting the file.)  This way the process
with permissions to modify /root/.ssh/authorized_keys can
verify the data it's putting in there and validate the credentials
of the user putting the data in.

You could instead leverage your sudo management scripts to
give users permissions to run scripts as root that modify
/root/.ssh/authorized_keys.  Here it's sudo, instead of
the script run by incron, controlling access. Anybody without
authorization gets a permission error.  As above, this approach
avoids the insecurity of suid root scripts.

Either way, the script the user runs must pick up the user's
username (or home directory, or whatever) itself.  This avoids
the problem of allowing one user to set permissions for another.
The trick for the script run via sudo would be to use logname(1).

So, writing a script (or scripts) to add/remove/replace lines in
/root/.ssh/authorized_keys does not sound all that much work,
although of course there are always devilish details.  flock(1) is
probably your friend if you write in shell.  You probably
want to log with logger(1), etc.

Regards,

Karl <kop at meme.com>
Free Software:  "You don't pay back, you pay forward."
                 -- Robert A. Heinlein

-- 
You are receiving this mail because:
You are the QA Contact for the bug.