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
Attachment:
signature.asc
Description: OpenPGP digital signature