Sudo? More like Su-doh: There's a fun bug that gives restricted sudoers root access (if your config is non-standard) It's only Monday, and we already have a contender for the bug of the week. Linux users who are able to run commands as other users, via the sudoer mechanism, though not as the all-powerful root user, can still run commands as root, thanks to a fascinating coding screw-up. This security vulnerability, assigned CVE-2019-14287, …
I had the misfortune to have to scratch the surface of sudo configuration recently, and there's a lot of stuff most people are probably unaware of, it certainly surprised me.
Sudo is really a terrible hack to get around the fact that by default Unix doesn't have a permissions system for things other than devices and files, so the granularity of privileged access is basically YES/NO. It's not how security should be done. Given the growing number of permissions and controls for containers perhaps there's hope for the future.
SELinux gives you more than the basic unix system
SELinux is rather like having both a hand grenade and a dog to protect you from intruders: at the critical moment you don't know which to deploy for the best and you can't use both because the dog is a retriever. After the event, though, a handy auditing tool will tell your next of kin what you should have done.
You're dead right, sudo is a terrible hack. Widespread because *Linux* doesn't have a privilege delegation model worth talking about. Solaris on the other hand has a very comprehensive privilege delegation model based on its RBAC system. So it is extremely simple for non-root processes to be granted the privilege to open privileged ports for example or start/stop system services without ever becoming or running as root. Unfortunately these "Enterprise" features have never made it into Linux which is still a developer-centric platform focused on audio and desktops to try and woo developers off Windows. Shame Solaris has no future.
It never ceases to amaze me what ingenuity people show when trying to do things while avoiding reading up on security properly. My excuse was no-one ever showed me the the 'how to do security properly' manual with enough authority for me to believe it was THE real manual.
I don't (thankfully)
if I need to allow -u someuser I'll put it in the sudoers[.d] definition. Occasionally I do though, for customer projects even. NO '!root' or anything similar either, I require explicit exact command matches! It makes the sudoers config file longer, but so what. It's anal retentive, but so what. Being anal retentive on security helps to prevent *this* sort of thing...
worth pointing out the 'pi' user on Raspbian has global sudo 'no password' access to EVERYTHING. Just sayin'. It's for convenience, of course, but if you do NOT change the 'pi' password, very VERY insecure.
That reminds me of a funny bug in my old Uni's PrimeOS machine (from ancient history). There were only three or five print jobs allowed per semester. However, the printer command had a # of copies option, which, of course, used a signed integer as argument. Therefore, using -1 copies would give you one more job to print :-)
I steer well away from any sudo function, as well as any Linux distro which claims not to have or need a Root function. As far as I'm aware, it's use is allow users to wield powers that root has, in order to load software, build the operating system, etc. I consider this to be absolutely the stupidest thing one can do. Having seen the catastrophes that users can do with normal user powers, the very last thing you need from a user is the ability to destroy the whole setup.In my day, the root password was the most guarded asset the system had, and was kept a long, long way fro the users.
For me, the whole point of it on production systems is to restrict control to certain processes that would otherwise require some form of god mode, which is even worse...
Want to let a user do some very basic management on Nginx but, nothing else? The following is relatively harmless and makes remote management a bit safer
# /etc/sudoers.d/nginx_knobby
knobby ALL=NOPASSWD: /bin/systemctl restart nginx
knobby ALL=NOPASSWD: /bin/systemctl start nginx
I agree with your opinion of sudo. It is the equivalent of leaving your front door key under the mat.
As it happens I use PCLinuxOS and Texstar holds even stronger views on the misuse of sudo and will not allow it near the distro, With su you have greater control over who can run as root and surely that must be a good thing.
Though looking at the downvotes not a lot of people agree.
"It is the equivalent of leaving your front door key under the mat"
Hmm.... More like, but not exactly the same as dividing your house up into multiple flats, and giving different people keys to their flats, with none of them getting access to the electricity/plumbing/utilities cupboard. A pretty good idea really, if you don't want to have to go and cook all their meals and do their washing, let them come and go as they please to non critical areas.
With su you have greater control over who can run as root and surely that must be a good thing.
With su you have next to no control, anyone who knows the root password can do anything, and you have no idea which actual user did it. No-one but the admin should have that password.
With sudo you can specify that user "x" can do speciific thing "y" as root, and only that. It also logs the fact that user 'x" did it. Far more secure in all respects.
Though looking at the downvotes not a lot of people agree
That's because they know how sudo works.
No-onebut the adminshould have that password.
That password should be (a) randomly generated, (b) kept in some secure place, with a mechanism which ensures that if it is ever extracted from that secure place for use it is replaced by a new randomly-generated password.
anyone with explicit access to the computer can boot up a CD/DVDROM Linux, chroot to the hard drive root [after properly mounting], and run passwd as root to reset things to whatever you want. Or, remove the hard drive, attach a USB-SATA adaptor to it, plug into "hacker laptop", switch to root, mount things, and reset the root password [using one of several methods].
SO randomly generated root passwords are ok I suppose, but there are limits to which any root password can be guarded like that.
better to just be safe, moderaly cryptic, limit who can access the computer [especially remotely] to avoid dictionary-based attacks, explicitly deny root logins via ssh, and so on.
You should be able to assign administration accounts only the rights actually needed in a "JEA security" type model.
Err, that is literally exactly what sudo does (bugs aside). Its configuration says which users can do which things as which users. Such as "members of this (administrative) group may stop/start this service".
I'd downvote you but for the fact you've currently got 42 downvotes.
'su' and 'sudo' are EXTREMELY important if you use ssh - you do NOT want to be able to ssh in and log in as root DIRECTLY. You just don't.
And how ELSE can you remote-admin a system without su and sudo ????
In FreeBSD there's one more restriction: you have to be a member of the 'wheel' group to su to root. So on my system you must ssh in as a very non-priv user, with a cryptic name. THEN you have to su to something in 'wheel' first, to be able to su to root.
And no sudo access for that user, either. And no root logins via ssh. su twice to get to root.
Thanks for the tip, ElReg.
(A quick eyeball of the systems I maintain show that none of them need the patch, as I expected ... Either I trust you with root, or you're stuck in your own little world with no need to edit the files of other users. I suspect that any greater granularity is lazyness on the part of the admin, or fuzzy-headed management making rules for dummies again.)
I suspect that any greater granularity is lazyness on the part of the admin
Not completely. I also only let su (with root password) access root. However a very restricted sudo is useful for allowing some users to run something I don't trust (for example, closed source software) as another user which does not have any access to their files (groups are used for access the other way so the user can communicate with the untrusted app).
However, as that names the specific user to use for the untrusted app it doesn't fall into this bug, fortunately.
Because the group of people you trust to be competent to deal with replacing disks on your systems are the same as the group you trust to be competent to restart the database, are the same as the group you trust to be able to run backups. And you, of course, trust all those people to be able to read the backup tapes, because, well, they're all good people who you trust to do anything.
Yes, 'fuzzy-headed managment' with their boring concerns about security.
This is sysadmin fascism. It is not you alone that decides who is to be trusted and who's not, business has also a word to say. You are supposed to do your best to work with database and application owners to manage risks not to impose your vision.
Also, may I remind you the not so few cases in which a trusted sysadmin locked down networks and systems and denied legitimate users access ?
Um, who do you think is deciding that various groups of people can perform various actions? Do you think it's the *nix sysadmin people? Seriously? Do you think the *nix sysadmin people have unconstrained root access without going through the correct elevation process to get it? How many people do you think are involved in approving the thousands of lines of sudo configuration that runs all this? Do you think it's just some sysadmin who makes it all up themselves? How quickly do you think the organisation would fail its audit if any of those things was true?
But hey, thanks for calling me a fascist.
"It is not you alone that decides who is to be trusted and who's not, business has also a word to say."
Methinks you misunderstood the main point. The main point was that giving unrestricted root access lets everyone with that access do anything. The business wouldn't want that. Nothing was said about the admins making all decisions; instead the admins would be better implementing a security policy limiting users' access to run stuff with root privileges.
"Also, may I remind you the not so few cases in which a trusted sysadmin locked down networks and systems and denied legitimate users access ?"
And how did they do that? By running commands as root. So if you give ten times as many people unrestricted root access, you have ten times as many people who could do something like that. And your disagreement with the original point was?
My disagreement is written in the first quote. It's about who decides to trust who. Hint, the word "alone".
As for the sysadmin locking legitimate users out, this is what happens when sysadmin decides he can't trust anybody else to come closer to his network/systems. If business decides to give ten other sysadmins the same level of privilege then that's it. The business is not really concerned with how many people have root privileges that will allow unrestricted access (otherwise they would never outsource systems administration). All they want is an environment where risks are managed and controls are in place and definitely not a place where a sysadmin consolidates his/her personal power.
Allow users to do their work with temporary limited admin privileges while making sure there's no room for laziness, sloppiness and mistakes. Do this and you'll earn a lot a respect as a sysadmin. Keep in mind it's not your server that you are managing.
This post has been deleted by its author
This post has been deleted by its author
If somebody really has that specific example in their sudo config, then bob pwns their box anyway, even after patching. As somebody else already wrote, you don't blacklist with sudo, you whitelist. with blacklisting, it's practically impossible to avoid holes. So I won't lose sleep over this.
sudo -u alice vi
:sh
sudo -u root bash
I don't know much about the top but it seem pretty bad at all to disallow -1. I don't know what happen if i do n-1 where n is root. So i tried at mac and it seems to work for any value where n is less then root id. So my question is. Does it fix at all this issue? Do we have any prove of concept that this solution works at all?
I read the code and seems to be a 0day patch and they will sun drop a new release. Linus should correct or fix the bug at all without the any hard code for now
There's more to this than meets the eye. What was publicized was one of the longest living zero-days exploits out there. Apparently in only very peculiar sudo configurations this sudo zero-day exploit was able to run as root. To be honest i never had heard of sudo until i started installing ubuntu and debian based linux distros. These people most damned know more of the whole story. Also the diff file going from version 1.8.27 and 1.8.28 is suddenly more than a million miles of lines long. Why so ? There's more to hide within sudo ? Therefor here's my sudo contribution for older Linux versions :
for Mandrake 10.1 and RedHat 7.3
ftp://ftp.crashrecovery.org/pub/linux/sudo/RPMS/mdk101/
Mandriva 2011
ftp://ftp.crashrecovery.org/pub/linux/sudo/RPMS/mdv2011/
Yes, we know, sudo had to be configured (im)properly for the bug to manifest itself. Not sure where you have an issue with that. A bug was found. It's been swatted. There will be more bugs to swat, eventually. It's what we do. (TINW) ... Onwards.
As for the diff file, I'm not sure what you are worried about. The tar archive for 1.8.28 is only about 0.5% (one half of one percent) larger than 1.8.27. The expanded archive is about 0.2% (two tenths of a percent) larger. This is easily within the range of what I would expect after reading (skimming, to be honest) the change log.
$ tar xzpf sudo-1.8.27.tar.gz
$ tar xzpf sudo-1.8.28.tar.gz
$ diff -uNr sudo-1.8.27 sudo-1.8.28 > sudo.diff
$ ls -l sudo-1.8.27.tar.gz sudo-1.8.28.tar.gz sudo.diff
-rw-r--r-- 1 root root 3293178 Oct 16 15:18 sudo-1.8.27.tar.gz
-rw-r--r-- 1 root root 3309744 Oct 16 15:15 sudo-1.8.28.tar.gz
-rw-r--r-- 1 root root 3654730 Oct 26 19:08 sudo.diff
$ wc -l sudo.diff
92512 sudo.diff
$
So the diff file going from 1.8.27 to 1.8.28 is 92.512 lines long, I wonder what caused this .
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
