Re: As seen above: use of su vs sudo
Am 07.08.2018 um 14:07 schrieb The Wanderer:
> On 2018-08-07 at 07:47, Martin wrote:
>
>> Am 07.08.2018 um 13:20 schrieb The Wanderer:
>>
>>> On 2018-08-07 at 05:58, Martin Drescher wrote:
>>>
>>>> Hi members,
>>>>
>>>> I'm a little... lets say thoughtful, about the use of 'su'
>>>> discussed at some points in this list. I have a strong opinion
>>>> about su, which is, avoid it whenever it is possible and use
>>>> 'sudo' instead. This is the case in close to a 100% in all cases
>>>> I can think of. This opinion is based on how both programs work
>>>> and deal with pam and environmental variables. Not to forget: You
>>>> will not need to share (or in my case, not even set, but lock
>>>> that account) a root password.
>>>>
>>>> And I'm curious why Debian still prefers the use of su over
>>>> sudo?
>>>
>>> I'm not sure where you get the idea that Debian does prefer that.
>>
>> It is not part of the base install. Besides the statement from
>> Jonathan Dowland earlier.
>
> I'm fairly sure that when I did (some of) my existing installs - which,
> to be fair, was years and years ago - sudo came with the system, even
> though I didn't even consider the concept of setting the machine up with
> no root password. Maybe this has changed at some point.
See Jonathan Dowland at 11:11 UTC.
>>> For my own machines to date (on most if not all of which I'm the
>>> primary if not sole user, or at least non-remote user), I don't
>>> even permit sudo to be installed. (Or at least I didn't, until I
>>> decided I wanted ubuntu-dev-tools - which depends on it - on one
>>> such machine. I may even revert that decision on further
>>> consideration.)
>>
>> 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.
> 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!
>>> My rationale for doing that is (in crude form) that to permit any
>>> root-level things to be done with an ordinary user's password -
>>> even mediated by a task-limiting mechanism such as I understand
>>> /etc/sudoers to be - is a security hole; not only is an ordinary
>>> user's password more likely to leak (whether by social engineering
>>> or by malicious code running as the user or by anything in
>>> between), if you're not trusted to have the root password in
>>> addition to your own, you shouldn't be doing any root-needing
>>> things in the first place.
>>
>> 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?
> If they aren't trusted enough to have that password, why are we
> permitting them to do anything root-level in the first place?
>
> That said, I recognize this concern, and it's a large part of why I
> moderated my position somewhat over the years.
>
>>> Over the years, I've moderated that position somewhat, enough to
>>> concede that there may be value in being able to hand out the
>>> ability to do some elevated-access things without handing out the
>>> ability to do all of them. That would just mean I'd want to set up
>>> various other (non-root, non-ordinary) users, with their own
>>> passwords and the necessary access to do those specific things, and
>>> hand out those passwords instead. (And
>>
>> 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?
> 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?
> (An alternative approach would be one "elevated" account per user, used
> only for elevated tasks and possibly even prohibited from logging in, so
> that if the user's normal password leaks that doesn't compromise
> elevated access. I think that would have too many downsides, however.)
>
>>> still probably have people use something like 'su -c' instead of
>>> sudo, unless sudo permits requiring the password of a user other
>>> than the one invoking the command.)
>>
>> 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. Than every individual has to set a password. May be even in some directory or so. 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 still maintain that making it possible to do an elevated thing with an
> ordinary-user password is a security hole; as long as sudo is designed
> around permitting that, it's not something I'm willing to use, much less
> recommend.
>
> Thanks for the pointer, however; it may lead to further developments,
> and I may even revise my position further based on those developments.
>
Reply to: