The sudo project has a short article about fine tuning access and logging for sudo. Sudo can be used for fine grained access to system level utilities and functions, though some distros have made it infamous by intentionally misconfiguring it to stand in for su. Unfortunately the example in the above article comes dangerously close to that by granting root access to the shell, Bash. So the better parts of the article about logging and JSON should be focused on instead:
Sudo had many features to help blue teams in their daily job even before 1.9 was released. Session recordings, plugins and others made sure that most administrative access could be controlled and problems easily detected. Version 1.9 introduced Python support, new APIs, centralized session recordings, however some blind spots still remained. Learn how some of the latest sudo features can help you to better control and log administrative access to your hosts. You will learn about JSON logging in sudo, chroot support, logging sub-commands, and how to work with these logs in syslog-ng.
The sudo blog has more coverage of available features.
(Score: 0) by Anonymous Coward on Saturday May 07 2022, @12:51PM (9 children)
The only command you really need.
(Score: 2) by maxwell demon on Saturday May 07 2022, @01:17PM (8 children)
The correct command is:
sudo make me a sandwich
The Tao of math: The numbers you can count are not the real numbers.
(Score: 2) by Opportunist on Saturday May 07 2022, @01:53PM (2 children)
sudo usermod -l a\ sandwich maxwell\ demon
There you go.
Though I really don't recommend spaces in usernames, so many scripts are badly written...
(Score: 0) by Anonymous Coward on Sunday May 08 2022, @01:54AM
The number of people who forget to quote variables in scripts is way too high.
(Score: 2) by Common Joe on Monday May 09 2022, @03:50PM
Yeah... I prefer the spaces because it's technically two words, but I learned my lesson. Soylent News is the last website I'll use with a space in my name. Not because of anything that Soylent News did or didn't do. Quite the contrary. I haven't had any problems on Soylent News at all with my username. It's just all kinds of problems elsewhere that I've encountered.
(Score: 2) by tangomargarine on Saturday May 07 2022, @01:56PM (2 children)
make: *** No rule to make target 'me'. Stop.
The joke doesn't work quite as well since there's an actual tool called "make"...
"Is that really true?" "I just spent the last hour telling you to think for yourself! Didn't you hear anything I said?"
(Score: 2) by maxwell demon on Saturday May 07 2022, @02:48PM
Well, feel free to complain to Randall Munroe.
The Tao of math: The numbers you can count are not the real numbers.
(Score: 2) by krishnoid on Sunday May 08 2022, @05:22AM
make: *** Ok, you're a sandwich. Stop.
(Score: 1, Funny) by Anonymous Coward on Saturday May 07 2022, @03:24PM
>> The correct command is:
>> sudo make me a sandwich
You aren't keeping up with the latest in systemd, since the correct command is now actually:
systemctl isolate sandwich-maker.target make.service start
(Score: 1, Funny) by Anonymous Coward on Sunday May 08 2022, @01:44AM
maxwell demon: "Sudo, make me a sandwich".
Sudo: "Well, okay, if you insist."
Sudo: (waves magic wand)
pyrotechnics: (Poof!)
props & stage crew: (replace maxwell demon with large sandwich prop.)
Sudo: "There, now you're a sandwich. I get the strangest requests".
(Score: 1, Insightful) by Anonymous Coward on Saturday May 07 2022, @01:15PM (6 children)
I'm the vast majority of cases, sudo doesn't do anything that couldn't be done with a proper application of permissions. This is more or less exactly what group permissions are for.
(Score: 2) by maxwell demon on Saturday May 07 2022, @01:20PM (5 children)
So how do permissions force you to enter your password?
And how do permissions cause logging of what you do?
The Tao of math: The numbers you can count are not the real numbers.
(Score: 3, Interesting) by Anonymous Coward on Saturday May 07 2022, @01:40PM
First off, the main reason for passwords with sudo is that it's often set up to allow you to run anything you want as root which is a massive security problem. There is little point unless you're leaving the terminal or allowed to run everything as root. *BSD doesn't typically include the utility as it is mostly just a security issue. If that's an issue, you probably should be reconsidering why they need access in the first place.
As for logging, that should never have been a part of the utility. If you can't trust people to run those commands, especially everything as root, logs aren't much help. But, if you just do it, then it should have been a part of the shell anyways. That way you get all of it, not just the portion after sudo is invoked. This can be fine in a few ways like rsyslog and just internally
(Score: 4, Informative) by RamiK on Saturday May 07 2022, @03:21PM (2 children)
I think he meant a properly setup system shouldn't require users to sudo in the first place. i.e. if some users need to mount external disks, there should be a group for that.
Any linux access-control list (SELinux.. AppArmor... Hell, GRSecurity even.) has log facilities. e.g. https://wiki.debian.org/SELinux/Setup [debian.org] enables auditd which can be made to log at user and file-level granularity whatever you want regardless if you actually have any security policies set in place. That is, you can use it just for logs if you want or you can use it for logs+security rules.
Besides, this sudo logging feature is just fragile and superfluous:
1. Sudo can be used to modify or delete the logs.
2. A user running "sudo ./foobar.sh", a python script or whatever would circumvent the logging. They can probably even run a nested repl (sudo sh/bash/python or whatever) and circumvent the log.
3. You could always just stick script [man7.org] in root's .bashrc or whatever and gain about the same level of logging.
4. You could couple a kernel level keylogger along with an ssh activity logger and get more reliable results. Not by much of course since it's still the wrong solution... But still.
Regardless, none of this is secure since the fundamental POSIX security model has no room for an untrustworthy root and only extensions like SELinux and co. has any chance at enabling a measure of flexibility around the POSIX rough edges.
compiling...
(Score: 1, Interesting) by Anonymous Coward on Saturday May 07 2022, @04:35PM (1 child)
Yes, a properly set up system should have little to no reason to have sudo installed, or even root access. Most tasks can be done without it, but things like mounting media are mostly restricted on some system because they interact with devices and can be used to load malicious programs.
There are some tasks like updating or installing software and adjusting firewalls that should require more access, but there isn't any inherent reason why that can't be handled via groups. But, it's a bit of a moot point as most modern operating systems have ACLs or the equivalent.
Really, sudo just makes it easier to engage in questionable security practices. The password is kind of a joke as it's usually the same password that's used on the account logging in which mostly just protects a bit against somebody sitting down and running it under somebody else's account.
(Score: 2) by Joe Desertrat on Monday May 09 2022, @01:16AM
It depends on what sort of system we are talking about. Sudo seems designed for home personal desktops, which is where I first ran across it. It's perfectly fine for that. In that case, it is who one allows to know the password that is the risk.
(Score: 0) by Anonymous Coward on Saturday May 07 2022, @04:50PM
As a side note, if you really need to run something that's extremely intrusive, like installing a new kernel or updating the OS, su -c will do it without the issues. Or, just log in directly as root of that's set up.
(Score: 5, Informative) by tangomargarine on Saturday May 07 2022, @01:53PM (2 children)
For those of us not familiar with what a "blue team" is, since TFA doesn't bother to explain:
"Is that really true?" "I just spent the last hour telling you to think for yourself! Didn't you hear anything I said?"
(Score: 0, Funny) by Anonymous Coward on Saturday May 07 2022, @03:26PM
I thought the Blue Team was the one that wanted to raise taxes.
(Score: 0) by Anonymous Coward on Sunday May 08 2022, @12:33AM
Thanks for the info. I thought it must be a Blue Man Group tribute band.
(Score: 2, Insightful) by Mojibake Tengu on Saturday May 07 2022, @03:39PM (4 children)
But the real damage was done at times when RedHat jerks removed the operator standard user from their system. Linux is fatally broken since then, by necessity of root for everything.
In my Universe, installing system software, configuring system software by rules and launching/terminating system software are three completely different roles.
It's a common consequence of new and promising boys effect that working things in software come badly degraded because some freshmen not understanding a true purpose of feature just remove it as useless. They don't se any use, but it is their insufficient range of mental horizon error.
But this one specifically is fatal to whole digital civilization. You broke it for real.
The edge of 太玄 cannot be defined, for it is beyond every aspect of design
(Score: 0) by Anonymous Coward on Saturday May 07 2022, @04:02PM (2 children)
> fatal to whole digital civilization
I'd not go that far. Nothing stops you adding an operator account, it's just easier for trusted users to be added to wheel. In over 20 years of using *nix, I've only ever (to my irritation) used sudo on OSX.
(Score: 1, Insightful) by Anonymous Coward on Saturday May 07 2022, @04:45PM (1 child)
That doesn't really solve the problem though, you've removed sudo from the equation, but now folks have a ton of access they probably don't need. The main point of wheel is to allow people to su to root, but unless you're the only person using the computer or are responsible for admin, you'd be better off with less access. Even if you are in control, it's not a bad idea to use a separate account entirely for su ing to root.
(Score: 0) by Anonymous Coward on Saturday May 07 2022, @07:55PM
If people can run commands as root, they are root.
The point of su'ing is to run commands as root, the main point of sudo is to run commands as root.
Then you should also be using a separate account for sudo unless you think a sudo su would be somehow "more betterer"?
(Score: 0) by Anonymous Coward on Saturday May 07 2022, @07:41PM
This is an example of the principle of Chesterton's fence [wikipedia.org], sometimes Chesterton's gate [wikipedia.org]. The recommendation is that anyone who wants to remove something isn't allowed to unless they can first explain why it is there. Just saying they don't see any reason for it is not enough.
My experience of being affected by this includes a hot-shot whizz-kid who "optimised"
Because aString often included strings similar to old-fashioned disk and tape identifiers (#123456) just after occurrences of the trigger character, this resulted in random, large scale memory overwrites, which were not at all easy to solve.
(Score: 3, Informative) by bzipitidoo on Saturday May 07 2022, @04:49PM (10 children)
In Ubuntu, I use "sudo su", since bare "su" doesn't work for going from luser to root. Really don't know why they bothered breaking su to root, when there is such a simple workaround. To "sudo su", still need the password, so it's not completely insecure. Once you have root access, you can su to any user you want, no password necessary.
The "build a wall" approach to security is, I believe, problematical. One tiny little hole, and the wall might as well not exist. Suppose, though, that there are no holes. Crossing it dozens of times every day is a massive pain. One of the biggest advances in the desktop environment is something real simple: automatic login.
One of the biggest remaining security stupidities is system update. In Ubuntu, the default is to automatically check for updates, then nag the user to enter a password, to authorize the update. If the user says no, it merely nags the user again a little while later. And what basis does the user have, to know whether or not to update? Usually, none! If the update has somehow been compromised, the user isn't going to know. Really, the only reason to ask, is to give users a chance to delay the update, because they have the computer busy doing something they don't want interrupted. That being the case, there is no need to demand a password, a simple "Update now? Yes or No" dialog would suffice. it's terrible default behavior. In one case, to shut it the heck up, I simply turned off automatic updating.
The system doesn't have a clear separation between physical and remote access. Often just slaps the same security on both.
(Score: 2) by RS3 on Saturday May 07 2022, @05:28PM (5 children)
I haven't run Ubuntu (nor Mint, etc.) for several years. Well, possibly running a "live" image for diagnostics, etc., but not regularly. I remember doing something to enable "su -", but I don't remember what I had to do. I just remember it was annoying and I felt like I was defeating some important security feature (that was easy to bypass). Might have been chmod su or something.
On the live systems I admin, sshd root login is blocked by default, and I make sure that it is not permitted in sshd_config.
So if I ssh (or putty or whatever) in, I have to start with a low permission user, then I su - . Yes, it's dangerous, and as an AC above commented, some "operator" or other mid-level security login would be safer. So far in 25+ years of Linux (and some older *nixes) I haven't done anything stupid as root. Backups of important stuff are done, some daily. They're not heavily edited / changed websites, and the owners all have local copies of their changes.
If you're physically at the server keyboard, you can log in directly as root (and it's a fairly big password).
(Score: 1, Informative) by Anonymous Coward on Saturday May 07 2022, @08:26PM
"sudo passwd root"?
I also block remote root login, and use su. I never understood the arguments against it. In over 20 years running servers and my own machines, I've never had a single mishap as root. Some of the pro-sudo arguments seem to presume the user is an idiot who'll use the root account for things other than administration. I never installed sudo as I remember there were quite a few vulnerabilities back in the day and they're still being found. [deepwatch.com] At least the security claims for sudo always struck me as nebulous at best.
(Score: 3, Informative) by bzipitidoo on Saturday May 07 2022, @10:03PM (3 children)
The main reason to cripple root is not to make the system harder to breach, it's to make it safer to admin.
The biggest threat I ever had to deal with was the developers demanding too much access. I'm all for the elimination of security theater, but in this case, we wanted the admin account for the database to be password protected, not to prevent breaches, but to prevent errors. The boss ruled in favor of the devs. For about half a year, all was well. Then, one day, it happened. The company's entire database was deleted in about one second. One moment, everything looks fine, and the next, our website isn't working, and a blizzard of warnings and errors is blasting us. Had we just been hacked? No. A system update had gone wrong. A dev had meant to update the test server, but accidentally pointed the update process at production. A simple password would have stopped this mistake before any damage could be done.
Lot of changes after that disaster. I rewrote the update process to make it far safer. The first thing the original did was "drop table" on all the tables. I changed it into a "pull" rather than a point and shoot method. Log into the machine that is to be updated, and start the process from there, rather than the old way of logging into the machine with the source code and pointing it at whichever server was to be updated. I also got rid of the suicidal "burn-it-all-down-to-nothing-then-rebuild" approach, changing that to make it install the new version alongside the working code, then, switch over, keeping the option to switch back in an instant, if there was some problem. No more of that "drop table" crap. Copy or rename the tables, that's the ticket.
(Score: 2) by RS3 on Sunday May 08 2022, @01:38AM (1 child)
Thanks. Yes, I understand and agree about root login. I live on the admin edge. I often think the day might come when I mistype an "rm -rf" from the wrong directory! But I wanted to rebuild that machine anyway, right? :)
Besides all the good details and wisdom in your post, I gleaned: why are corporate political structures so horribly bad, wrong, moronic, and too often disastrous? You should have the power (VP / CTO) to make final decisions on everything admin. Especially after the disaster you mentioned (that you wisely saw coming).
Probably my biggest career disappointment is having non-technical bosses overrule me on technical decisions. In my current job, fairly small company, skeleton crew, I have a lot of latitude, and I pretty much get to make the decisions and act on them. And they're usually to everyone's benefit.
My only comment about password protection: it's too easy to have automatic logins. Even if people have to type them in every time, they'll probably have them written down somewhere.
One place I've done some work: they had live and development servers, and they were on different subnets, not routed, so you had to do some extra work to get to the live server. A lot of it was before my time there, but I could envision not allowing the devs (they were mostly sharp graphic artists who did some coding) to post to the live server- admins only. Sometimes specialization causes problems (where I work we have too many "silos", or "walled gardens") but sometimes it's a Good Thing.
(Score: 0) by Anonymous Coward on Sunday May 08 2022, @01:55PM
I love zfs, as long as I didn't have any significant changes after the last snapshot, that's a non issue. But, really, this is what permissions are supposed to address, no write access unless you actually need to write.
(Score: 1, Interesting) by Anonymous Coward on Sunday May 08 2022, @02:56AM
We have had some testing/production mixups but sudo itself helped prevent damage. The reason is that the passwords requested by testing machines are different from production machines. Working along and you forget you are on one but not the other, the fact that sudo keeps rejecting your password is a really big clue.
(Score: 1, Interesting) by Anonymous Coward on Sunday May 08 2022, @01:18AM (1 child)
Wouldn’t "sudo -i" get you a root prompt a bit more elegantly?
(Score: 0) by Anonymous Coward on Sunday May 08 2022, @02:00PM
I think so, but isn't sudo -i just supposed to leave you effectively logged into sudo for whatever it's configured to let you do rather than full root anything you want to do?
(Score: 0) by Anonymous Coward on Monday May 09 2022, @12:21PM (1 child)
"sudo su -" means "as root, become root, and start a root login shell". It makes me weep.
Just use "sudo -i", people will stop laughing at you behind your back.
(Score: 2) by bzipitidoo on Monday May 09 2022, @03:04PM
You'll really love the trick I use to find files, when "locate" isn't available:
du -a | grep filename
(Score: 3, Insightful) by hopdevil on Saturday May 07 2022, @06:13PM (1 child)
Thinking about how companies typically do security, sudo is a huge gaping hole and should be disabled. In most large systems, you can expect to find any user which has any access to also have sudo access.. and you would hope that requires a password but it most often does not. Users often get access with either some central login manager or authorized key.
The better alternative is to enable remote root login, where each user who needs to have root access has a unique key. Better yet, lock those keys up and only divvy then out when actually needed (preferably one that expires). ssh supports login by signed certificates, this is what I use and it is really simple to setup.
Track who has and uses root access. Monitoring for root login is much easier than figuring out if sudo was used inappropriately. The need for root level access should be very rare or a "never" occurrence on most systems. If you use certificates, the real user can be embedded in one of the fields and shows up in the logs.
The security of the individual system and the entire network should be done deliberately, through a central mechanism rather than hoping things will "just work out" when a user logs into a box.
(Score: 0) by Anonymous Coward on Sunday May 08 2022, @01:20AM
Better yet, just use Microsoft Windows servers so you don't have to worry about security.
(Score: 1) by tbuskey on Sunday May 08 2022, @03:34PM
When you create a firewall, you block everything 1st
Then you allow only what is needed, as narrowly as possible.
Most times sudo is so the root password isn't shared. And everything is open
Most people using sudo don't do it for security. Maybe they do it so the end user has accept/pause before commands.
Its better than typical (past?) Windows practices where the user has admin rights built in to their login.
If you want to use sudo for real security, you need a locked down sudoers file. And its is hard.
First don't allow everything, just like a firewall.
Log everything and read the logs.
You need full paths to commands and the user needs to type them too ex: /bin/ip, /usr/bin/apt
You can't use commands that let you shell out like vi, emacs.
You need to watch for scripts the end user can edit.
I've only seen one locked down sudoers and I was allowed to edit my script.
In the end, its best to reduce the need for root as much as possible.
(Score: 0) by Anonymous Coward on Sunday May 08 2022, @04:20PM (1 child)
i thought "sudo" is so you don't have to type "exit" like you have to do after "su"?
also my "su" gets me into DOS mode >:D
(Score: 0) by Anonymous Coward on Sunday May 08 2022, @09:09PM
It's supposed to be set up so you can only use it with specific commands to somewhat limit the damage that can be done, but that's how it tends to be set up on many systems by default.