[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: As seen above: use of su vs sudo



On 2018-08-07 at 08:27, Martin wrote:

> Am 07.08.2018 um 14:07 schrieb The Wanderer:
> 
>> On 2018-08-07 at 07:47, Martin wrote:

>>> As a system operator, you need some elevated privileges on a
>>> daily basis. How do you do that without sudo?
>> 
>> No, I don't. I only need them when I'm doing elevated things, such
>> as installs or upgrades. (In practice on some machines, I do those
>> on around a weekly basis or slightly more frequently, but it can
>> be argued that that's overkill.) The overwhelming majority of what
>> I do does not require elevated privileges, and the few things
>> which do are not needed anywhere near daily.
> 
> Starting and stopping services (e.g. running systemctl), changing
> configurations, all things you, where individual decisions have to
> be made, reuire elevated privileges. root in many cases.

And none of those are things I need to do as frequently as on a daily
basis.

>> How I do them is by running either "su -c 'command name'", or
>> simply running 'su' and then running the desired command(s) and
>> then exiting the root shell.
> 
> So, what is bad with 'sudo -u TARGETUSER YOUR_COMMEND'? How do you
> edit a file with su? Invoke a shell? Take a look at sudoedit!

"su OPTIONAL_USERNAME -c 'YOUR_COMMAND'", or similar, where
'YOUR_COMMAND' could be 'nano /path/to/file-to-be-edited' - or could be
'sh', if it weren't possible to get a root shell by just running
straight 'su' instead.

>>> The point is not, that ONE person needs a root password. All 
>>> people intended to do privileged things will have to share this 
>>> password. This is a security nightmare!
>> 
>> If they're all trusted enough to be trusted with that password in 
>> the first place, this isn't a problem, any more than the one
>> person having it is.
> 
> Come on. You are telling me, it is more secure to share one secret 
> among multiple people against every person having it own?

Of course not.

But it's more secure to require a second password to do elevated things
than to permit doing those things with the same password as is used for
ordinary activities.

>>> So you are spreading even more passwords around the world... No.
>> 
>> How is this less secure than permitting "anyone who happens to 
>> discover the password of $random_user" to do (some) root-level 
>> things?
> 
> First you have to log in to a user's account. And I'm quite sure,
> you will use ssh with keys that, right?

Not usually; this is a desktop machine, not a server. Most logins are
done from a position of physical access.

Also, part of my entire point is that the "let users type their password
to confirm authorization to do elevated things" approach means that
anyone who learns the user's password can *both* log in as the user
*and* do those elevated things, which is clearly less secure than if
that just made it possible to log in as that user.

>> At the very worst, it means that if the 
>> limited-access-for-this-role password leaks, you A: just have to 
>> change that one password and B: haven't had the entire system 
>> compromised.
> 
> What?

I'm not sure what you're asking.

>>> Ok, you have not read the sudo man page, neither understood the 
>>> concept. And why you do _not_ want to use 'targetpw'. No
>>> offence, but you really need to thin about your thesis on
>>> privilege management.
>> 
>> The relevant man page is actually sudoers, and you're right; I did
>> search it for 'user' and "password" in the hopes of finding a way 
>> to do this, but apparently managed not to find this term, even 
>> though it's there. That does open up some interesting 
>> possibilities.
> 
> Please, don't use 'targewtpw'. It is evil. Thin about that: Every 
> individual has to log in on a shell. SSH keys are used for that.

I think this may be our first point of disconnect. I'm not expecting
most, or even a significant fraction of, logins to be done remotely.

I originally approached this from the model of a shared physical
computer (and monitor, and keyboard, and so forth), which has different
people sitting down in front of it - logged in with their own accounts,
either local or network-authenticated - at different times of day.

Most users might not even be authorized for SSH login in the first
place.

(I'm not sure I fully understand SSH key-based login, but I'm also not
entirely comfortable with what I think it would require in order for
someone to be able to log in from whatever random computer they happen
to be at; I would expect that to result in too much risk of the keys
being exposed.)

> Than every individual has to set a password. May be even in some
> directory or so.

I'm not quite sure what you're talking about here. The user's password
must already exist in order for the user to log in, because the password
gets set when the user's account gets created. Are you talking about
some additional password, attached to the same user account? And what
directory are you talking about? (Is this a reference to LDAP, rather
than to filesystem-type directories?)

> This password is _only_ used to authenticate a user in a certain
> shell, to the person he claims to be. This is two factor 
> authentication: SSH login, then password. When this was successful, 
> sudo starts evaluating against stuff in the sudoers file and it's 
> offspring.
> 
> Yes, this is way more complex than su. But it will improve system 
> security by far, when in good hands.

I'm not entirely sure I understand this proposal.

If the password is only used to authenticate the user in the shell, then
it must not also be used to authenticate the user to sudo, because that
would mean the "only" doesn't apply.

I can't quite seem to articulate what else about this I find confusing,
but that's not the only thing...

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man.         -- George Bernard Shaw

Attachment: signature.asc
Description: OpenPGP digital signature


Reply to: