Re: sudoers question
On Sat, May 13, 2023 at 09:07:19AM -0700, Kushal Kumaran wrote: [...] > The benefit is that there is no shared password. [...] Thanks. This is one very good point indeed. Cheers -- t signature.asc Description: PGP signature
Re: sudoers question
On Sat, May 13 2023 at 01:51:03 AM, Lee wrote: > On 5/12/23, DdB wrote: >> Am 13.05.2023 um 00:03 schrieb Lee: >>> On 5/12/23, Stefan Monnier wrote: > Or configure sudo to disable tty_tickets, so that the timeout (10 > minutes by default IIRC) applies to all terminals. `sudo bash` anyone? >>> >>> me! me! but I also have >> (...) >>> %adm ALL = (root) NOPASSWD: ADM_COMMANDS >> >> Of course, there are ways to allow any/all sudo commands without >> password. And i also have to cast a warning here: >> >> The kind of mistakes, any user (including yourself) can initiate, grows >> considerably, if he can use any commands without even thinking. > > In general, yes, but how much trouble can > /usr/bin/dmesg, > /usr/bin/apt list > /usr/bin/apt update > /usr/sbin/checkrestart > /usr/sbin/needrestart > cause? > > OTOH, I like the idea of logging in as root to do admin stuff. But > that seems to be frowned on now.. I don't know why :( .. unless > logging? 'sudo bash' or logging in as root doesn't leave an audit > trail of commands you've done > The benefit is that there is no shared password. If one of the people entrusted with sudo privileges needs to lose those privileges (perhaps because they leave the organization), removing that user account stops their access. If, on the other hand, you were allowing admins to login as root, you now need to change the shared root password. Of course, this requires a degree of locking down. For example, the set of users allowed to do day-to-day administration tasks must not overlap with the set of users permitted to modify the sudo configuration or set root password. You can also have different sets of users permitted to do different kinds of administrative tasks: one group might be permitted to stop/restart a small set of services, for example. And no one can be permitted to do `sudo bash` or its equivalent. Logging is a nice additional benefit, and some organizations may be required to keep audit logs for server configuration changes. sudo providing this will be a bonus for them. On single-user systems, the ability to do NOPASSWD for selected commands is nice. I don't know of any other benefit. -- regards, kushal
Re: sudoers question
to...@tuxteam.de wrote: > Security is engineering: always looking for a good tradeoff. > Not magic. > > (That's why I cringe when people around here scaremonger about > "you NEED to have a password" and things. People should know > what they are getting into, for sure, but at the same time they > should take their own decisions). Yes but -- if someone asks for advice and clearly doesn't know the tradeoffs they are making, the first advice should be to take the safer option. Pointing them at the documentation after that is good. -dsr-
Re: sudoers question
wrote: > On Sat, May 13, 2023 at 10:35:31AM +0200, Michel Verdier wrote: > > Le 12 mai 2023 tomas a écrit : > > > > >> > `sudo bash` anyone? > > >> > > >> also quicker done with > > >> su - > > > > > > But not the same. > > > > Which differences do you see ? > > For su, you have to enter the root password. For sudo, there > are many options, depending on config. Typically you enter > yours. > > Plus, you can configure which commands (and args) can be done > by whom, based on user id, local or remote, etc. > > OTOH the sudo system is way more complex than simple su, so > there's more place where bugs can hide (it has had actual > issues, btw). > > Security is engineering: always looking for a good tradeoff. > Not magic. > > (That's why I cringe when people around here scaremonger about > "you NEED to have a password" and things. People should know > what they are getting into, for sure, but at the same time they > should take their own decisions). > > Cheers Not to mention that su - uses the --login option, whilst sudo bash doesn't.
Re: sudoers question
DdB (12023-05-13): > The kind of mistakes, any user (including yourself) can initiate, grows > considerably, if he can use any commands without even thinking. You are right with this principle but you are mistaken in applying it. If you want to teach users to think before typing the password, then making sure commands that are obviously harmless do not ask for the password. There are harmless commands that for some reason require privileges. Configuring sudo to permit them without password is a good idea. Regards, -- Nicolas George signature.asc Description: PGP signature
Re: sudoers question
On Sat, May 13, 2023 at 10:35:31AM +0200, Michel Verdier wrote: > Le 12 mai 2023 tomas a écrit : > > >> > `sudo bash` anyone? > >> > >> also quicker done with > >> su - > > > > But not the same. > > Which differences do you see ? For su, you have to enter the root password. For sudo, there are many options, depending on config. Typically you enter yours. Plus, you can configure which commands (and args) can be done by whom, based on user id, local or remote, etc. OTOH the sudo system is way more complex than simple su, so there's more place where bugs can hide (it has had actual issues, btw). Security is engineering: always looking for a good tradeoff. Not magic. (That's why I cringe when people around here scaremonger about "you NEED to have a password" and things. People should know what they are getting into, for sure, but at the same time they should take their own decisions). Cheers -- t signature.asc Description: PGP signature
Re: sudoers question
Le 12 mai 2023 tomas a écrit : >> > `sudo bash` anyone? >> >> also quicker done with >> su - > > But not the same. Which differences do you see ?
Re: sudoers question
On 5/12/23, DdB wrote: > Am 13.05.2023 um 00:03 schrieb Lee: >> On 5/12/23, Stefan Monnier wrote: Or configure sudo to disable tty_tickets, so that the timeout (10 minutes by default IIRC) applies to all terminals. >>> >>> `sudo bash` anyone? >> >> me! me! but I also have > (...) >> %adm ALL = (root) NOPASSWD: ADM_COMMANDS > > Of course, there are ways to allow any/all sudo commands without > password. And i also have to cast a warning here: > > The kind of mistakes, any user (including yourself) can initiate, grows > considerably, if he can use any commands without even thinking. In general, yes, but how much trouble can /usr/bin/dmesg, /usr/bin/apt list /usr/bin/apt update /usr/sbin/checkrestart /usr/sbin/needrestart cause? OTOH, I like the idea of logging in as root to do admin stuff. But that seems to be frowned on now.. I don't know why :( .. unless logging? 'sudo bash' or logging in as root doesn't leave an audit trail of commands you've done > To my eye, as there is a huge responsability involved with using > elevated powers, i would not want "my little brother" to accidentally > sit in front of my computer while just trying commands at a console, > that he may have heard of somewhere. I gave login credentials to a 4 yr old :) I was a bit apprehensive when he started mashing the keyboard but I'd already tried to find all the world-writeable files on the machine so I wasn't all _that_ worried. I'm more concerned that I did the search wrong & missed some thing than I am of getting a "rm -fr /" from random keyboard mashing. > Even worse: When i found out, how to prevent sudo from asking a pwd, i > in fact did cause a couple of bad mistakes, that the system would > otherwise have prevented from happening (including making it > unbootable). And it took my quite some time in order to get used to some > kind of a routine, that keps me from having to reinstall everything from > scratch after each mishap. > > So, after some time, i have become way more cautious at allowing too > many powers to myself without thinking. And especially the OP did reveal > some contradictory habits: > He was asking, how to allow any sudo command without being asked for a > password ( which means: without being controlled by the system ). On one > hand, this could make sense under certain premises. > OTOH, he was failing to display any kind of responsible attitude for the > job (like as if reading logfiles was hs only interest ...). > > Just simply asking for help in this regard let me wonder, as i had been > able to find out all this without even knowing about his group, > including the relevance of sudoedit in this regard (which no one even > mentioned). > > You can't have your cake and eat it too! > > If we (as a community) would support such a behavior, wouldn't we be > responsible for the effecs, this entails No. > Would you hand out a loaded weapon to a child? (I certainly did not.) Maybe I have? But this is a personal/household machine so if files get deleted I'll get to find out if my backup/restore process works as well as I hope it does :) At work, downtime is expensive, so I do tend to lock things down at work. At home I'm a lot more casual. Regards Lee
Re: sudoers question
Am 13.05.2023 um 00:03 schrieb Lee: > On 5/12/23, Stefan Monnier wrote: >>> Or configure sudo to disable tty_tickets, so that the timeout (10 >>> minutes by default IIRC) applies to all terminals. >> >> `sudo bash` anyone? > > me! me! but I also have (...) > %adm ALL = (root) NOPASSWD: ADM_COMMANDS Of course, there are ways to allow any/all sudo commands without password. And i also have to cast a warning here: The kind of mistakes, any user (including yourself) can initiate, grows considerably, if he can use any commands without even thinking. To my eye, as there is a huge responsability involved with using elevated powers, i would not want "my little brother" to accidentally sit in front of my computer while just trying commands at a console, that he may have heard of somewhere. Even worse: When i found out, how to prevent sudo from asking a pwd, i in fact did cause a couple of bad mistakes, that the system would otherwise have prevented from happening (including making it unbootable). And it took my quite some time in order to get used to some kind of a routine, that keps me from having to reinstall everything from scratch after each mishap. So, after some time, i have become way more cautious at allowing too many powers to myself without thinking. And especially the OP did reveal some contradictory habits: He was asking, how to allow any sudo command without being asked for a password ( which means: without being controlled by the system ). On one hand, this could make sense under certain premises. OTOH, he was failing to display any kind of responsible attitude for the job (like as if reading logfiles was hs only interest ...). Just simply asking for help in this regard let me wonder, as i had been able to find out all this without even knowing about his group, including the relevance of sudoedit in this regard (which no one even mentioned). You can't have your cake and eat it too! If we (as a community) would support such a behavior, wouldn't we be responsible for the effecs, this entails? Would you hand out a loaded weapon to a child? (I certainly did not.) just saying ... good luck DdB
Re: sudoers question
On 5/12/23, Stefan Monnier wrote: >> Or configure sudo to disable tty_tickets, so that the timeout (10 >> minutes by default IIRC) applies to all terminals. > > `sudo bash` anyone? me! me! but I also have # cat /etc/sudoers.d/adm-grp-privs # members of adm can run certain commands as root without supplying # a password # Andrei POPESCU Sun, Dec 5, 2021 at 10:46 AM # To: debian-user@lists.debian.org # Re: Don't try this at home kids Cmnd_AliasADM_COMMANDS = /usr/bin/dmesg, \ /usr/bin/apt list, \ /usr/bin/apt update, \ /usr/sbin/checkrestart, \ /usr/sbin/needrestart, \ /usr/sbin/reboot %adm ALL = (root) NOPASSWD: ADM_COMMANDS Regards Lee
Re: sudoers question
On 2023-05-12, Tom Reed wrote: >> Tom Reed (12023-05-12): >>> otherwise every time i have to input password for sudo. >> >> Yes, that is the point. >> >> If “every time” is a lot for you, maybe your use habits need to be >> reviewed. >> > > that's normal. for example, I have to check every kind of logs (mail, > webserver, systems etc). They require sudo then. > > regards > > Certain people here who don't use sudo on single human user systems used to say they'd keep a root terminal open at all times (with some kind of cautionary reddish prompt to remind them of the inherent power) for convenient switching to administrative work. That's if you have no cat or child or other malicious creature in the vicinity, of course.
Re: sudoers question
On Fri, May 12, 2023 at 05:46:21PM +0200, Michel Verdier wrote: > Le 12 mai 2023 Stefan Monnier a écrit : > > >> Or configure sudo to disable tty_tickets, so that the timeout (10 > >> minutes by default IIRC) applies to all terminals. > > > > `sudo bash` anyone? > > also quicker done with > su - But not the same. Cheers -- t signature.asc Description: PGP signature
Re: sudoers question
Le 12 mai 2023 Stefan Monnier a écrit : >> Or configure sudo to disable tty_tickets, so that the timeout (10 >> minutes by default IIRC) applies to all terminals. > > `sudo bash` anyone? also quicker done with su -
Re: sudoers question
On 12/05/2023 21:00, Byung-Hee HWANG (황병희) wrote: On Fri, 2023-05-12 at 08:25 -0400, Stefan Monnier wrote: `sudo bash` anyone? AMAZING! Thanks for tip, Stefan ^^^ Isn't it a way to get e.g. ~/.bash_history owned by root? sudo -i should be better
Re: sudoers question
Hi Stefan, On Fri, 2023-05-12 at 08:25 -0400, Stefan Monnier wrote: > > Or configure sudo to disable tty_tickets, so that the timeout (10 > > minutes by default IIRC) applies to all terminals. > > `sudo bash` anyone? > AMAZING! Thanks for tip, Stefan ^^^ Sincerely, Byung-Hee -- ^고맙습니다 _布德天下_ 감사합니다_^))//
Re: sudoers question
Le 12 mai 2023 Tom Reed a écrit : > that's normal. for example, I have to check every kind of logs (mail, > webserver, systems etc). They require sudo then. Logs are with adm gid, so just add your user to the group adm to be able to consult logs.
Re: sudoers question
Stefan Monnier (12023-05-12): > `sudo bash` anyone? Why not “sudo start-gnome” or logging as root on the display manager while you are at it? Regards, -- Nicolas George
Re: sudoers question
> Or configure sudo to disable tty_tickets, so that the timeout (10 > minutes by default IIRC) applies to all terminals. `sudo bash` anyone? Stefan
Re: sudoers question
Greg Wooledge (12023-05-12): > If you're launching a terminal, running a single sudo command, closing > the terminal, opening a new terminal, etc. ... then perhaps you should > stop doing that. Leave your terminal open, at least until you're done > with whatever administrative task you're doing. Or configure sudo to disable tty_tickets, so that the timeout (10 minutes by default IIRC) applies to all terminals. Regards, -- Nicolas George
Re: sudoers question
On Fri, May 12, 2023 at 08:13:31PM +0800, Tom Reed wrote: > that's normal. for example, I have to check every kind of logs (mail, > webserver, systems etc). They require sudo then. If you check the logs all at once, as part of a daily routine, then you only have to type the password one time, at the beginning of your log-checking session. The second, third, fourth, etc. sudo commands will all use the cached credentials that you supplied the first time. You might also consider adding "tom" to the "adm" group, so that "tom" can read most of the system log files without needing sudo.
Re: sudoers question
On Fri, May 12, 2023 at 07:27:25PM +0800, Tom Reed wrote: > Hello > > what's the right way to add an user to run sudo without password? > I have to edit /etc/sudoers by manual. But I don't think it's a grace way. > > Thanks. > Tom > As others have said: sudo is *designed* this way - you have to prove your identity once and then you get some time in the session before you would have to reinput a password. If you don't appreciate why this is important, I would respectfully suggest that you go and read up on computer security. It is also worth reading up on restrictions on commands and forced commands: you can create a group such that users can only perform one command. For example, backupusers as a group and then configure sudo to *only* allow the members of that group to use a backup command. Hope this helps, Andy Cater
Re: sudoers question
Tom Reed (12023-05-12): > that's normal. for example, I have to check every kind of logs (mail, > webserver, systems etc). They require sudo then. No they do not. You just have to adjust files permissions if they are not correct by default, which they usually are. My crystal ball tells me you neglected to add yourself to the adm group. Regards, -- Nicolas George
Re: sudoers question
On Fri, May 12, 2023 at 08:03:00PM +0800, Tom Reed wrote: > for a common account, such as tom, a nopasswd sudo also makes sense? > otherwise every time i have to input password for sudo. Within a given terminal session, you only have to enter your passwors once. This will allow passwordless sudo on that terminal for the next 15 minutes (by default). If you're launching a terminal, running a single sudo command, closing the terminal, opening a new terminal, etc. ... then perhaps you should stop doing that. Leave your terminal open, at least until you're done with whatever administrative task you're doing.
Re: sudoers question
> Tom Reed (12023-05-12): >> otherwise every time i have to input password for sudo. > > Yes, that is the point. > > If “every time” is a lot for you, maybe your use habits need to be > reviewed. > that's normal. for example, I have to check every kind of logs (mail, webserver, systems etc). They require sudo then. regards
Re: sudoers question
Tom Reed (12023-05-12): > otherwise every time i have to input password for sudo. Yes, that is the point. If “every time” is a lot for you, maybe your use habits need to be reviewed. Regards, -- Nicolas George
Re: sudoers question
> On Fri, May 12, 2023 at 07:27:25PM +0800, Tom Reed wrote: >> what's the right way to add an user to run sudo without password? >> I have to edit /etc/sudoers by manual. But I don't think it's a grace >> way. > > *Without password*?? Yes, that will require a manual edit. > > There is no "graceful way" to grant that power to users, because that's > an obscene amount of power without a check. Usually one would only > do this for a non-interactive account (some sort of service/daemon > account that does an automated backup, or something of that nature). > > Hello Greg, for a common account, such as tom, a nopasswd sudo also makes sense? otherwise every time i have to input password for sudo. Thanks
Re: sudoers question
On Fri, May 12, 2023 at 07:27:25PM +0800, Tom Reed wrote: > what's the right way to add an user to run sudo without password? > I have to edit /etc/sudoers by manual. But I don't think it's a grace way. *Without password*?? Yes, that will require a manual edit. There is no "graceful way" to grant that power to users, because that's an obscene amount of power without a check. Usually one would only do this for a non-interactive account (some sort of service/daemon account that does an automated backup, or something of that nature).
sudoers question
Hello what's the right way to add an user to run sudo without password? I have to edit /etc/sudoers by manual. But I don't think it's a grace way. Thanks. Tom
