Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #198352 > unrolled thread

As seen above: use of su vs sudo

Back to article view | Back to linux.debian.user

Contents

  As seen above: use of su vs sudo Martin Drescher <keine-eile@online.de> - 2018-08-07 12:00 +0200
    Re: As seen above: use of su vs sudo Joe <joe@jretrading.com> - 2018-08-07 12:50 +0200
      Re: As seen above: use of su vs sudo Jonathan Dowland <jmtd@debian.org> - 2018-08-07 13:20 +0200
        Re: As seen above: use of su vs sudo Martin Drescher <keine-eile@online.de> - 2018-08-07 13:30 +0200
          Re: As seen above: use of su vs sudo David Wright <deblis@lionunicorn.co.uk> - 2018-08-07 17:20 +0200
            Re: As seen above: use of su vs sudo Martin <keine-eile@online.de> - 2018-08-07 17:40 +0200
              Re: As seen above: use of su vs sudo Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2018-08-07 18:20 +0200
        Re: As seen above: use of su vs sudo Joe <joe@jretrading.com> - 2018-08-07 14:10 +0200
          Re: As seen above: use of su vs sudo likcoras <likcoras@riseup.net> - 2018-08-07 14:40 +0200
      Re: As seen above: use of su vs sudo likcoras <likcoras@riseup.net> - 2018-08-07 14:00 +0200
    Re: As seen above: use of su vs sudo Richard Owlett <rowlett@cloud85.net> - 2018-08-07 13:00 +0200
    Re: As seen above: use of su vs sudo Stephan Seitz <stse+debian@fsing.rootsland.net> - 2018-08-07 13:20 +0200
      Re: As seen above: use of su vs sudo James Allsopp <jamesaallsopp@googlemail.com> - 2018-08-07 13:30 +0200
        Re: As seen above: use of su vs sudo Curt <curty@free.fr> - 2018-08-07 13:50 +0200
          Re: As seen above: use of su vs sudo Stephan Seitz <stse+debian@fsing.rootsland.net> - 2018-08-07 14:30 +0200
            Re: As seen above: use of su vs sudo Martin <keine-eile@online.de> - 2018-08-07 14:30 +0200
          Re: As seen above: use of su vs sudo Jonathan Dowland <jmtd@debian.org> - 2018-08-07 15:20 +0200
            Re: As seen above: use of su vs sudo Martin <keine-eile@online.de> - 2018-08-07 15:50 +0200
        Re: As seen above: use of su vs sudo <tomas@tuxteam.de> - 2018-08-07 14:20 +0200
        Re: As seen above: use of su vs sudo Dave Sherohman <dave@sherohman.org> - 2018-08-07 15:30 +0200
      Re: As seen above: use of su vs sudo Martin <keine-eile@online.de> - 2018-08-07 13:40 +0200
        Re: As seen above: use of su vs sudo Stephan Seitz <stse+debian@fsing.rootsland.net> - 2018-08-07 14:30 +0200
    Re: As seen above: use of su vs sudo The Wanderer <wanderer@fastmail.fm> - 2018-08-07 13:30 +0200
      Re: As seen above: use of su vs sudo Martin <keine-eile@online.de> - 2018-08-07 13:50 +0200
        Re: As seen above: use of su vs sudo The Wanderer <wanderer@fastmail.fm> - 2018-08-07 14:10 +0200
          Re: As seen above: use of su vs sudo Martin <keine-eile@online.de> - 2018-08-07 14:30 +0200
            Re: As seen above: use of su vs sudo The Wanderer <wanderer@fastmail.fm> - 2018-08-07 15:00 +0200
              Re: As seen above: use of su vs sudo Nicolas George <george@nsup.org> - 2018-08-07 15:10 +0200
                Re: As seen above: use of su vs sudo The Wanderer <wanderer@fastmail.fm> - 2018-08-07 15:30 +0200
                  Re: As seen above: use of su vs sudo Nicolas George <george@nsup.org> - 2018-08-07 15:40 +0200
                    Re: As seen above: use of su vs sudo David Wright <deblis@lionunicorn.co.uk> - 2018-08-07 18:20 +0200
                      Re: As seen above: use of su vs sudo Nicolas George <george@nsup.org> - 2018-08-07 18:40 +0200
                        Re: As seen above: use of su vs sudo Greg Wooledge <wooledg@eeg.ccf.org> - 2018-08-07 18:50 +0200
                      Re: As seen above: use of su vs sudo Michael Stone <mstone@debian.org> - 2018-08-07 19:10 +0200
                        Re: As seen above: use of su vs sudo Curt <curty@free.fr> - 2018-08-07 20:10 +0200
                          Re: As seen above: use of su vs sudo Nicolas George <george@nsup.org> - 2018-08-07 20:10 +0200
                            Re: As seen above: use of su vs sudo Curt <curty@free.fr> - 2018-08-07 20:20 +0200
                          Re: As seen above: use of su vs sudo Michael Stone <mstone@debian.org> - 2018-08-07 20:50 +0200
              Re: As seen above: use of su vs sudo Martin <keine-eile@online.de> - 2018-08-07 15:10 +0200
                Re: As seen above: use of su vs sudo The Wanderer <wanderer@fastmail.fm> - 2018-08-07 15:30 +0200
                  Re: As seen above: use of su vs sudo Michael Stone <mstone@debian.org> - 2018-08-07 15:50 +0200
                  Re: As seen above: use of su vs sudo Martin <keine-eile@online.de> - 2018-08-07 15:50 +0200
              Re: As seen above: use of su vs sudo Nemeth Gyorgy <friczy@freemail.hu> - 2018-08-07 21:10 +0200
                Re: As seen above: use of su vs sudo Gene Heskett <gheskett@shentel.net> - 2018-08-07 22:10 +0200
            Re: As seen above: use of su vs sudo Michael Stone <mstone@debian.org> - 2018-08-07 15:20 +0200
            Re: As seen above: use of su vs sudo Stephan Seitz <stse+debian@fsing.rootsland.net> - 2018-08-07 16:10 +0200
          Re: As seen above: use of su vs sudo Dave Sherohman <dave@sherohman.org> - 2018-08-07 15:30 +0200
            Re: As seen above: use of su vs sudo The Wanderer <wanderer@fastmail.fm> - 2018-08-07 15:40 +0200
          Re: As seen above: use of su vs sudo David Wright <deblis@lionunicorn.co.uk> - 2018-08-07 18:10 +0200
    Re: As seen above: use of su vs sudo Eike Lantzsch <zp6cge@gmx.net> - 2018-08-07 14:30 +0200
    Re: As seen above: use of su vs sudo mick crane <mick.crane@gmail.com> - 2018-08-07 16:00 +0200
    Re: As seen above: use of su vs sudo mick crane <mick.crane@gmail.com> - 2018-08-07 18:30 +0200

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

#198370

> I don’t know if Debian does, but the difference between su and sudo seems quite like to the difference between ssh logins with password and with keys. Both have advantages and disadvantages.

By far: No.
su only invokes or acts like login, pam included. sudo may represent a complex role management.

It's like su calls: Let me log in as TARGET_USER, I have the password. Done.

Using sudo, you call for for a specific privilege. Which may be a command or a login shell, when using 'sudo -i TARGET_USER'.
sudo then decides, based on your current UID and GID, with wwhich UID and/or GID you want to claim what privilege, if this will be granted. And then you may, which is the default, type in YOUR user password to authenticate your self.

Martin

[toc] | [prev] | [next] | [standalone]

#198386

[Multipart message — attachments visible in raw view] — view raw

On Di, Aug 07, 2018 at 01:33:20 +0200, Martin wrote:
>> I don’t know if Debian does, but the difference between su and sudo 
>> seems quite like to the difference between ssh logins with password 
>> and with keys. Both have advantages and disadvantages.
>By far: No.
>su only invokes or acts like login, pam included. sudo may represent a complex role management.

Yes, I know. Maybe I wasn’t clear enough. Both tools provide a solution, 
and it is your philosphy/rule set that will decide if solution A is 
better for your work or solution B.

Shade and sweet water!

	Stephan

-- 
| Public Keys: http://fsing.rootsland.net/~stse/keys.html |

[toc] | [prev] | [next] | [standalone]

#198368

[Multipart message — attachments visible in raw view] — view raw

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.

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.)

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.

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
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.)

-- 
   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

[toc] | [prev] | [next] | [standalone]

#198375

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.

> 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?

> 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!

> 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.

> 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.


Martin 

[toc] | [prev] | [next] | [standalone]

#198380

[Multipart message — attachments visible in raw view] — view raw

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.

>> 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.

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.

>> 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.

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?

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.

(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.

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.

-- 
   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

[toc] | [prev] | [next] | [standalone]

#198387

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.
> 

[toc] | [prev] | [next] | [standalone]

#198393

[Multipart message — attachments visible in raw view] — view raw

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

[toc] | [prev] | [next] | [standalone]

#198394

[Multipart message — attachments visible in raw view] — view raw

The Wanderer (2018-08-07):
> "su OPTIONAL_USERNAME -c 'YOUR_COMMAND'"

The superiority of sudu over su in this particular case is that it does
not require an extra level of quoting.

> 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.

That not necessarily true. A second password used for rare cases often
means a password on a post-it under the keyboard.

> 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.

Anyone who learns the user's password can obtain the second password
pretty easily.

Also, remember that what is really precious is access to user accounts.
Root access is only a means to access any user's account. On a
single-user machine, it is one and the same.

Regards,

-- 
  Nicolas George

[toc] | [prev] | [next] | [standalone]

#198402

[Multipart message — attachments visible in raw view] — view raw

On 2018-08-07 at 09:09, Nicolas George wrote:

> The Wanderer (2018-08-07):
> 
>> "su OPTIONAL_USERNAME -c 'YOUR_COMMAND'"
> 
> The superiority of sudu over su in this particular case is that it
> does not require an extra level of quoting.

I don't consider that a significant downside; in some contexts, it may
even be an advantage.

>> 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.
> 
> That not necessarily true. A second password used for rare cases
> often means a password on a post-it under the keyboard.

An inclination in the direction of doing that would be a mark against
that user being considered sufficiently trustworthy to have the elevated
access to begin with.

>> 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.
> 
> Anyone who learns the user's password can obtain the second password 
> pretty easily.

How so?

> Also, remember that what is really precious is access to user
> accounts. Root access is only a means to access any user's account.
> On a single-user machine, it is one and the same.

There's a point there, but I do consider the rest of the system (beyond
just the user's account) to be something worth securing, even on a
single-user system.

-- 
   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

[toc] | [prev] | [next] | [standalone]

#198405

[Multipart message — attachments visible in raw view] — view raw

The Wanderer (2018-08-07):
> I don't consider that a significant downside;

Maybe your uses are too limited for you to experience it.

>						in some contexts, it may
> even be an advantage.

No, it may not. With sudo, adding "sh -c" allows to emulate su's
behaviour. On the other hand, su cannot emulate sudo's behaviour at all.

> An inclination in the direction of doing that would be a mark against
> that user being considered sufficiently trustworthy to have the elevated
> access to begin with.

I was referring to the real world, not wishful thinking.

> > Anyone who learns the user's password can obtain the second password 
> > pretty easily.
> How so?

Just insert a fake su in their path. There are more subtle ways.

> There's a point there, but I do consider the rest of the system (beyond
> just the user's account) to be something worth securing, even on a
> single-user system.

Maybe. But it does not need to be *more* secure than the user's account.

Regards,

-- 
  Nicolas George

[toc] | [prev] | [next] | [standalone]

#198415

On Tue 07 Aug 2018 at 15:31:43 (+0200), Nicolas George wrote:
> The Wanderer (2018-08-07):

> > > Anyone who learns the user's password can obtain the second password 
> > > pretty easily.
> > How so?
> 
> Just insert a fake su in their path. There are more subtle ways.

This does make me wonder why nobody here seems to have pointed out
that su should be spelled "/bin/su -". My fingers have been wired
that way for 20 years.

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

#198418

[Multipart message — attachments visible in raw view] — view raw

David Wright (2018-08-07):
> This does make me wonder why nobody here seems to have pointed out
> that su should be spelled "/bin/su -". My fingers have been wired
> that way for 20 years.

As I said, there are more subtle ways, and the full path will not
protect you from them.

Regards,

-- 
  Nicolas George

[toc] | [prev] | [next] | [standalone]

#198419

On Tue, Aug 07, 2018 at 06:29:58PM +0200, Nicolas George wrote:
> David Wright (2018-08-07):
> > This does make me wonder why nobody here seems to have pointed out
> > that su should be spelled "/bin/su -". My fingers have been wired
> > that way for 20 years.
> 
> As I said, there are more subtle ways, and the full path will not
> protect you from them.

wooledg:~$ function /bin/su { echo haha; }
wooledg:~$ /bin/su root
haha

Just one of many ways a malicious user can compromise the interactive
environment.  An even better one is to run a key logger, to capture the
root password when you type it in their X session.

[toc] | [prev] | [next] | [standalone]

#198422

On Tue, Aug 07, 2018 at 11:14:26AM -0500, David Wright wrote:
>On Tue 07 Aug 2018 at 15:31:43 (+0200), Nicolas George wrote:
>> The Wanderer (2018-08-07):
>
>> > > Anyone who learns the user's password can obtain the second password
>> > > pretty easily.
>> > How so?
>>
>> Just insert a fake su in their path. There are more subtle ways.
>
>This does make me wonder why nobody here seems to have pointed out
>that su should be spelled "/bin/su -". My fingers have been wired
>that way for 20 years.

Because it's unnecessary extra typing?

[toc] | [prev] | [next] | [standalone]

#198427

On 2018-08-07, Michael Stone <mstone@debian.org> wrote:
> On Tue, Aug 07, 2018 at 11:14:26AM -0500, David Wright wrote:
>>On Tue 07 Aug 2018 at 15:31:43 (+0200), Nicolas George wrote:
>>> The Wanderer (2018-08-07):
>>
>>> > > Anyone who learns the user's password can obtain the second password
>>> > > pretty easily.
>>> > How so?
>>>
>>> Just insert a fake su in their path. There are more subtle ways.
>>
>>This does make me wonder why nobody here seems to have pointed out
>>that su should be spelled "/bin/su -". My fingers have been wired
>>that way for 20 years.
>
> Because it's unnecessary extra typing?
>

I thought his point might be that in typing the full path at least you
know you're getting '/bin/su' and not some other 'su' that a malevolent
individual might have created in your home directory after prepending HOME
to your path, for example (in that malevolent person's effort to elevate
himself to superuser status). 

Maybe he didn't mean that, though, and I've got things all wrong (famous
last words).



-- 
Some years ago, when the images which this world affords first opened upon me,
when I felt the cheering warmth of summer and heard the rustling of the leaves
and the warbling of the birds, and these were all to me, I should have wept to
die; now it is my only consolation. --Mary Shelley, Frankenstein; or, The Modern Prometheus

[toc] | [prev] | [next] | [standalone]

#198428

[Multipart message — attachments visible in raw view] — view raw

Curt (2018-08-07):
> I thought his point might be that in typing the full path at least you
> know you're getting '/bin/su' and not some other 'su' that a malevolent
> individual might have created in your home directory after prepending HOME
> to your path, for example (in that malevolent person's effort to elevate
> himself to superuser status). 

Indeed. It protects you from semi-competent crackers. With incompetent
ones, is is not needed, with competent ones it is useless. You judge if
it is worth the hassle.

Regards,

-- 
  Nicolas George

[toc] | [prev] | [next] | [standalone]

#198429

On 2018-08-07, Nicolas George <george@nsup.org> wrote:
>
> Curt (2018-08-07):
>> I thought his point might be that in typing the full path at least you
>> know you're getting '/bin/su' and not some other 'su' that a malevolent
>> individual might have created in your home directory after prepending HOME
>> to your path, for example (in that malevolent person's effort to elevate
>> himself to superuser status).=20
>
> Indeed. It protects you from semi-competent crackers. With incompetent
> ones, is is not needed, with competent ones it is useless. You judge if
> it is worth the hassle.

The hassle seems minimal, whereas the category of the semi-competent
appears to be fairly well-populated.

Of course, I'm a touch typist, so YMMV. 

> Regards,
>

-- 
Some years ago, when the images which this world affords first opened upon me,
when I felt the cheering warmth of summer and heard the rustling of the leaves
and the warbling of the birds, and these were all to me, I should have wept to
die; now it is my only consolation. --Mary Shelley, Frankenstein; or, The Modern Prometheus

[toc] | [prev] | [next] | [standalone]

#198430

On Tue, Aug 07, 2018 at 06:01:27PM +0000, Curt wrote:
>I thought his point might be that in typing the full path at least you
>know you're getting '/bin/su' and not some other 'su' that a malevolent
>individual might have created in your home directory after prepending HOME
>to your path, for example (in that malevolent person's effort to elevate
>himself to superuser status).

Yes, it's just a completely useless thing to do for most plausible 
attack scenarios. Typing unnecessary characters to possibly protect 
yourself from one extremely specific (and frankly unlikely) attack seems 
more superstition than science; in a couple of decades of looking at 
compromised computers, I can't recall ever running across an attack in 
the wild that depended on someone typing "su" and not "/bin/su".

Mike Stone

[toc] | [prev] | [next] | [standalone]

#198396

Am 07.08.2018 um 14:50 schrieb The Wanderer:
> 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.

Ouch!
Once you let a user run an editor with escalated privileges, you're fu**ed. In almost every editor, you can load a different file, save the buffer with a different file name. 
That is, why I pointed out the use of 'sudoedit'. You need to warp your mind around it, from a security standpoint, the use of 'su' is not a good idea in almost all cases.
And I still have no idea, what the single case would be, where sudo would not be able to do, what you may accomplish using su.

[...]

[toc] | [prev] | [next] | [standalone]

#198404

[Multipart message — attachments visible in raw view] — view raw

On 2018-08-07 at 09:04, Martin wrote:

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

>>> 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.
> 
> Ouch!
> 
> Once you let a user run an editor with escalated privileges, you're
> fu**ed. In almost every editor, you can load a different file, save
> the buffer with a different file name.

Of course.

Again, that comes down to: do you trust this user with elevated access,
or not?

If you don't, you shouldn't be giving them elevated access of any kind.

If you do, then giving them this access doesn't hurt.

If you trust them with only limited elevated access, you should be
giving them access to a more limited role, not to root itself. It may be
reasonable to do that via sudoers (probably with targetpw, though I
haven't finished considering that subject), but it's also reasonable to
do it with separate users for each role.

(Combined with the fact that I didn't say I'd let most users do this; I
said this is what I do myself.)

> That is, why I pointed out the use of 'sudoedit'. You need to warp
> your mind around it, from a security standpoint, the use of 'su' is
> not a good idea in almost all cases.

I'm aware of this tool. It's not something I've ever needed, but it's
certainly valid for its purpose.

> And I still have no idea, what the single case would be, where sudo
> would not be able to do, what you may accomplish using su.

It's not that you can do something with su that you can't do with sudo.

It's that you can do things with sudo that you can't do with su.

Or, rather, that you can do elevated-access things with the same
credentials as are used to permit non-elevated access.

I consider that to be, by definition, a security hole.

-- 
   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

[toc] | [prev] | [next] | [standalone]

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

Back to top | Article view | linux.debian.user

csiph-web