Oh ****... Sudo has a 'make anyone root' bug that needs to be patched – if you're unlucky enough to enable pwfeedback Sudo, a standard tool on Unix-y operating systems that lets select users run some or all commands as root, can be exploited to give superpowers to any logged-in user – if deployed with a non-default configuration. This security hole, discovered by Joe Vennix at Apple Information Security, is only active if the pwfeedback …
Just for completenss: Microsoft implemented RBAC on a higher scale with Windows 8 / Server 2012, though it is possible since Windows NT 4.0 (could not test NT 3.x). But they kept UAC for a good reason, and I recommend setting it to the highest level. So it has both. It is time for *ix to have RBAC available on a broad scale, not just a hand full distros.
Doesn't help if it RBAC is not used though - no matter which OS.
No, you let only those entitled to log in as root do so. Part of the problem is that although early Unix had multiple user IDs for different tasks these all got handed back to root eventually. Why, for instance, couldn't a specific non-root user have rights over installing S/W in /usr/local?
"Why, for instance, couldn't a specific non-root user have rights over installing S/W in /usr/local?"
Just make a group that contains the users you want to be able to write to /usr/local, and chown the directory to that group. I don't think Linux can handle nested groups, which is a nuisance.
Of course, that basically gives the person root access because they can replace parts of the OS with Folger's Crystals that will then be used by everyone else, including the root user.
I prefer that the Specific Non-Root User install software in a subdirectory of their home directory. If they want to let others use the software, they can set permissions to give those others read+execute rights. Best of all, none of this requires special permission from the server admin. If compiling from source code, just build it in the location you choose. RPM packages use an environment variable to make it very easy to do exactly this. I assume that Debian packages have similar.
Even a BOFH should do most things with an account other than root. I don't think we're asking the janitor to install applications - though if they're reliable then why not - but to have different hats, as it were, representing different tasks.
Of course, to swap hat momentarily, you use sudo (or su). Whoops!
If you want, you can make it very easy for nonroot users to do lots of things, including adding restrictions to exactly which users can do those things. The utility of sudo is that, should you want to change what they can do, it's a lot easier. Say you do want to allow some users to modify /usr/local, but not to have other root permissions. We're using this as an example, but in reality that would be a terrible thing to let them do as that would provide them a great deal of access to mess up everything.
If you do it the old way, by adding them to a group and assigning /usr/local to that group, it's easy. Anyone in the group gets the access you set. If you want to remove that permission, you kick the user out of the group. Easy. Unless you left the company and I'm running the system now, because I don't necessarily know all your groups and what you let them do. You've probably documented it somewhere, but that might be for some systems but not others, or somebody lost your documentation, etc. So now there are users whose access I can't cut off because I don't know it exists. I could do a global check of the filesystem to see if there are any unusual owners or groups, and after I find this first one I probably will, but it's not at all something a new admin would be expecting.
There's another classic way to expose functionality to users: a program running as root that receives user commands. The program itself has root capabilities, but the user doesn't. They issue the command they'd like, and that program determines if they have the rights to execute that command and does so. This works well too, and it lets you introduce even finer controls on what someone can do. So, for example, you can block them from installing a compromised copy of a utility over an old one, but continue to allow them to write new files in there. This is harder for the user, as they'll have to learn how your program works. It's also harder for you, because you'll have to write the program. It's a little easier for me, because your program will either have to have a server component which gets started on boot (thus I can easily see it) or at least it'd be in a directory on a path. Of course, if I don't have source code for this program, my life is really annoying.
Now, we have sudo. Sudo is limited, and it can have flaws. No question about that. But it allows you to relatively easily define who is allowed to do what. It can require their password, so even if someone gets access to an open terminal of theirs or one of their SSH private keys, they can't elevate easily. Your program could do that, but only by replicating sudo's functionality to a certain degree, and the owner and group solution doesn't give you that option at all. It's easier for the user because the commands are nearly always the same. It's much easier for me. If I want to know who has special access, specifically what, and what they do with it, I can find all of that in the sudo configuration files and logs. It's one place, and it's now common enough that it's a typical place to check when administrating a new system.
...a program running as root that receives user commands...
This is also a potential security hole; you'd better make sure your program has no flaws, or buffer overflow exploits, and if it allows a user to run certain other commands with root privileges, then those programs themselves have no such flaws.
By doing this via a common well-recognised route (sudo), you reduce that attack surface to only the vulnerabilities in sudo itself. Admittedly, in cases such as this, if sudo has a buffer overflow flaw, then you've got a problem. However, a known flaw (that gets patched, hopefully very quickly) is better than a hundred unknown flaws that may be getting exploited for years without you knowing anything about them.
Security is hard. Rolling your own is almost never the right solution. I am, frankly, astounded that something as basic and ubiquitous as sudo has such a flaw, not least because I would have expected it not to have changed substantially in many years. Whoever is responsible for doing that particular code-review needs a spanking, as does whoever is responsible for doing a security audit of the build. After all, a root escalation exploit in a tool used for controlled root escalation is an obvious place to look for well known flaws such as buffer overflows.
And
- RBAC is not configured the same way on all platforms
- RBAC may have different capabilities on each platform/version
- Having to configure a person into different RBAC 'groups' on each platform is inefficient/error prone or requires more automation to be built/tested/patched.
- Producing a unifired audit trail across all RBAC platforms is probably either not feasible or painful.
- Not sure how well automation tools support RBAC configuration across platforms
And sudo has none of those issues? Seriously? If you use bog standard plain sudoers setups, then sure, maybe you have a point. Once you start throwing different sudo plugins (such as this one!) into it or fancy things like AD groups or what not, I'm sorry, your point starts to become less valid. The ONLY point left is that there's probably already some sudo template for your automation system that you can steal and hope that it pretty much does the right thing.
Lack of templates sounds more like an issue with your automation/testing platform and not a problem with RBAC itself. Any decent system out there can already handle the platform differences for you, just like it does for everything else (eg, different shells).
Most *IX flavors, and even Linux, have supported RBAC for a long time. It’s just that people use sudo because they’re lazy and setting up RBAC correctly takes effort.
You write this as if laziness is a bad thing. Some people describe getting the desired result with the minimum of effort as being lazy. Others call it achieving maximum productivity.
It depends. If you can do lazy AND correct, then awesome, that's ideal!
If the two choices are lazy OR correct, then in the majority of the time, lazy is wrong answer. I myself am guilty of going "It's just temporary, I'll redo it the correct way later when I have time!". Of course, that almost never happens, unless something forces your hand. It's the exact same reason most people don't run daemons in proper chroot jails even though chroot has been around for so long.
Look at the multitude of sudo security issues over the years and then tell me with a straight face that all of that was worth it. There is no reason that a distro couldn't ship a decent default RBAC setup and tools to make it easier for the users to modify them. If RHEL can setup &#$ SELinux "properly" out of the box, which is almost infinitely more complex, then there's just simply no excuse at this point.
"It was right decades ago, but its time is up..."
I partially concur: the suid-mechanism is not exactly one of the strong design points of Unix and basing a central component of user authentication and authorization on it is suboptimal to say the least - particularly if said component is a rather complex program written in C...
One of the few things that Windows does indeed better than Unix is that admin privileges do not depend on a well known UID but on group membership to begin with, which eliminates the need of contraptions like sudo just in order to avoid shared admin passwords.
Making things worse, sudo tries to be a poor man's RBAC and makes a rather poor job of it too.
(Note that the whole concept of RBAC, while being a good idea in principle, is totally flawed if it is not fully supported by the kernel's security reference monitor from ground up. E.g. the idea of allowing a user to install random software in system locations without conferring additional privileges is a complete fallacy on Unix: you'd need MAC-based security plus labels on each file a user creates /plus/ a mechanism in the SRM to ensure that a program installed by user X can /never/ run with any privileges X did not have at the time of the program file's creation - good luck with that one.)
... admin privileges do not depend on a well known UID but on group membership ...
That's only a cosmetic difference. Sudo itself can use group-based permissions, though whether you gain anything is unclear. I know, from years of involvement, that Windows' group-based permissions also degenerate into an unholy mess as soon as you need anything non-trivial.
I'd argue that if the flaw is in the source (even if not the default configuration) then the flaw is in the compiled code. Whether it's turned on or off is largely moot, the alarming thing is that such a flaw exists in sudo.
If by "configuration", what is being talked about is whether the code in question is compiled in or not (i.e. due to an #IFDEF section), then it's slightly less alarming, although still alarming that such flawed code should make its way into the "official" source.
I am assuming here that such things are tightly controlled, and someone somewhere is responsible for maintaining an "official" source for the sudo command. Presumably, it's low-level enough to be distributed with the kernel (I've never dug into the innards of *nix enough to know, TBH, I don't fancy losing myself in that particular time sink). I would guess that various distros don't go around rolling their own forks of sudo for shits and giggles, because frankly, as a security practice, that would smell very bad.
Seems sensible. Presumably both of those distros are including a version of sudo that comes from the same verified source (if not the same version). Wikipedia tells me it is maintained by Todd Miller, but doesn't reveal whether it is a team effort, or entirely the fault work of one man...
I consider myself suitable chastened.
Of course, I would expect sudo is available in many if not all types of *nix, not just the penguin-flavoured ones. I'm assuming it's the same in all of these, although I will confess to not knowing much about the deep innards of various OSs - presumably various *nix flavours bear enough similarity for sudo to operate in the same way in each, and for it to be compiled from the same source (potentially with OS dependent libraries)?
It does highlight the chain-of-trust that is assumed with tools such as this, and the potential need for some forensic analysis of flaws in such...
Surely it only needs 1 or the other? Pos = buffsize - remaining or remaining = buffsize - pos
You never maintain 2 variables that can consistently and easily be derived from eadh other unless speed is
absolutely critical because you get exactly these sort of issues,
I'm probably a bit older on that version. Though I have done updates at times. Will check the folders.
Irritating such a simple feature gets a buffer overload. Could they not just match keypresses to * without passing the actual characters (to the faulty pwfeedback)? Faulty by design IMO, as my bro in the field says "if the data is never there, you can never accidentally leak it!"
I remember the concerns about Sudo when I was in grad school, 92-4.
After init and your shell, if there is one service that you must get right to ensure system integrity, sudo is it. Looking at the bugs in sudo that have come out in the last five years, I cannot help but think that this service was never architected with security in mind. Certainly, the steady drip of whoopsies says that it is not being maintained as if it were a critical security service.
Currently, sudo.c and sudo.h appear to be a bit over 57k. Of course, if you take the entire source directory, you get more like 300k, including several files that are specific to OS or tty.
I would argue for a complete clean room implementation, but historically, the expected behavior has been as ripe for failures as the implementation. Anyone up for safesudo?
Beer, 'cause I'm crying in it.
I would ask the follow-up-question, "why has sudo been changing in the last five years"? Sounds like feeping creaturism to me. Such things are never good for software stability, and something security critical like sudo should do the job it is supposed to do, with the minimum of code and fuss, and stop there.
I'm a little upset that I'm only now finding out that this option even existed. Five years ago I had to google high and low to find out why the hell I couldn't type my password into the terminal (first time Linux user then), and when I finally asked on a forum I was told "Get used to it pleb. Type it correctly and it's not a problem!" or something to that effect. So I did. But I didn't need to when I was learning the ins and outs. #$@!
This feels like if your dad kept tossing you down a hill on your bicycle until you got it, then half a decade later you see a kid on training wheels.
Training wheels actually encourage the wrong behaviour, because you lean out of corners....
They are usually considered to be counter productive when learning to ride a bike.
And it is the same reason that most people can't ride a tricycle, they tend to throw you out of the path at the first corner, whether there is a wall or a hedge there is of no concern.
But if they're leaning over your shoulder they can hear how many keys you hit, so they know how long your password is anyway, plus they can probably see which keys you pressed.
On the other hand, for people who aren't as comfortable using computers, not being able to see if they've typed a character or not can be very confusing, which leads to more wrong passwords, which leads to more support calls.
Cue me on the phone having to persuade someone to try typing in a password again even though they're convinced they've already typed it in correctly.
I'm sure the response to this will be "well they should learn to type better", from the exact same people who wonder why Linux isn't more widespread.
On a similar tack, LUKS disables the capslock light, because apparently if someone can see when you've turned capslock on as you type your password, that's too insecure. Yes, there are many people out there who don't understand the shift key, and will type capital letters by pressing \capslock on/ *letter* \capslock off/, and I deal with some of those people on a daily basis. Even just an option to allow the 'insecure capslock light' would save me a few support calls, but no.
I'm sorry to be the one to say this to you, but... If you're in IT (seeing as this is a IT site) and you still type slow enough where somebody can easily count the keystrokes, then maybe it's time for you to find a new vocation :(.
I might not type properly or even as accurate as a professional typist, but after years of IT I can at least type fast enough where clicks aren't totally easy to count.
Although I totally agree about the Caps Lock thing, that's just totally stupid. I normally at least check the LED status to make sure it's NOT on before I type my password!
... was implemented (poorly) to shut up a bunch of users who couldn't deal with password entries not echoing anything. This was the behavior of terminal based utilities since the first days of Unix. Part of the reasoning was that echoing anything back (like an asterisk) could allow a shoulder surfer to count the number of characters in one's password, making attacks easier. So patch requests were addressed with a WONTFIX. But the whining continued. And this is what we got.
If you cry long and hard enough, you can even get systemd.
Gods forbid that an OS should be usable by normal people. After all, the biggest threat from someone stood close enough to count the number of asterisks on your screen is that they could count the characters in your password, rather than just watching which keys you press, right?
So am I right in thinking that "sudo make me a sandwich" will not allow me to have beetroot as well?
I love sudo /bin/bash and then do the work since a lot of things don't sudo well. Mostly it for my lazyness for ssh keyexchange and then keyauth without the need for a password for automated jobs (or Orcale and a few other applications...). Which brings in the other weakness that 0/0 is always root. Everywhere...
Another thing I prefer about windows in comparison. My main machine has:
Name : Administrator
SID : S-1-5-21-620362388-xxxxxxxxxxx-xxxxxxxxxx-500
My Server 2019 (workgroup, I am at home):
Name : Administrator
SID : S-1-5-21-3213853355-xxxxxxxxxx-xxxxxxxxxx-500
So upon installation (or image cloned with sysprep, as example) those numerous local account (Administrator, guest, default etc etc) get their own sid. On every machine.
Only the first part and the last is the same, documented at https://support.microsoft.com/en-us/help/243330/well-known-security-identifiers-in-windows-operating-systems
I do like Linux and unix, but some things about its design bothered me over decades, and still bothers me.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2025
