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