Re: [dev] Privilege escalation on remote hosts. MANY remote hosts.

From: Kamil Cholewiński <harry666t_AT_gmail.com>
Date: Thu, 21 Sep 2017 22:42:04 +0200

> What about using custom public SSH keys that force the execution of a
> specific command/script instead of the default login shell?

The operational principle is that first you scp a script with arbitrary
content, written in an arbitrary language, to the remote box(es), then
execute the said script with elevated privileges. I'm using mktemp(1)
here (so that two sessions doing two different things can run in
parallel), but even if the script name was known ahead of time, this
dance wouldn't make sense, as it would be writable by the same user that
can later use 0-factor sudo on it.

$ sudo sh
[sudo] password for kamil: ^C
$ echo 'exec sh' > bin/superscript
$ chmod +x bin/superscript
$ sudo -n bin/superscript
# id -u
0

Although it somewhat does help prevent the "drunk admin typing at the
wrong ssh window" problem, it smells like security through obscurity.

> The best solution is likely making an admin account on each box that has
> access to the things you need to control. make it a system account but keep
> the users shell in /etc/passwd
> then, use gpg to login and do the business. that way, the only way to login
> to that account is through SSH or with local root. otherwise passwd asks
> for a password that does not exist.

I'm sorry, but I'm not following. What's the role of GPG in this
scenario? Which machine(s) have the admin account: local or remote?

Remote: one scenario we must consider is when there is more than one
user with admin privileges on the remote box(es). If the remote machine
has a shared admin account, we lose the ability to trace actions back to
an individual user (source IP address is easily obscured). If we
provision a more restricted and a less restricted account for each user,
the user will just use whichever one has less friction, defeating the
purpose of having two accounts.

Local: admin access on control machine should never be assumed. Think:
shared jumpbox / bastion. I'd like to give developers admin access on
web hosts in the DMZ, but not on the bastion. Bastion should be able to
run Judo seamlessly (and non-interactively too).

Thanks for the input!

<3,K.
Received on Thu Sep 21 2017 - 22:42:04 CEST

This archive was generated by hypermail 2.3.0 : Thu Sep 21 2017 - 22:48:19 CEST