51–60 of 60 posts
Earlier quoted context omitted.
I have no idea what he is referring to but being able to "Run as Administrator" as any user is sketchy.
I’m pretty sure only administrators can Run as Administrator?
For anyone with a modicum of C spending any amount of time in the sudo codebase, this isn't much surprise. It's the scariest piece of organically grown security-sensitive code I'm aware of still in popular use. It's jam-packed with features you've never even heard of, and has quite surprising functional changes across versions that never make the changelog and require diffing to discover. It's hard to quantify that "…
> Ignoring the implementation, I think it's fair to say sudo is broken in concept IMO you're not going far enough. The whole UNIX setuid notion is fundamentally broken to me. The ability to execute a file should logically have nothing to do with the permissions granted to you when doing so. Windows gets this right.
No date at all in the article. It helps to have that for context.
Date: Mon, 14 Oct 2019 09:00:31 -0600Earlier quoted context omitted.
Which UAC bypasses have they refused to fix?
He's probably referring to [1], but he's wrong about UAC (note the sentence "UAC is not a security feature" on that post—the fact that he himself had to put quotes around "security" is itself telling), and moreover, I never claimed anything about UAC in the first place. He's ignoring my point and changing the topic, so I'm not inclined to reply. [1] https://devblogs.microsoft.com/oldnewthing/20160816-00/?p=94...
There is an almost comical list of bypasses in built-in AutoElevate programs that Microsoft does not triage as security bugs because as you note they don't call UAC a security feature. I think this is a rather silly deflection that users are unlikely to understand, for good reason.
I have a hard time understanding this explanation: > For example, it can be used by a local user who wants to run commands as root — the windows equivalent of admin user. "root" is the "windows equivalent" of "admin user"? But then he talks about rules where you give someone the "sudo" permission to run a command as anyone _other_ than root > jacob myhost = (ALL, !root) /usr/bin/chmod > This entry means that user jac…
Correct.
Letting a normal user run commands as root is the most common use-case for sudo, which is why it was mentioned as an example earlier.
The bug does not trigger in this common setup, only in a quite unusual one mentioned later. Perhaps that should have been said explicitly.
Earlier quoted context omitted.
He's probably referring to [1], but he's wrong about UAC (note the sentence "UAC is not a security feature" on that post—the fact that he himself had to put quotes around "security" is itself telling), and moreover, I never claimed anything about UAC in the first place. He's ignoring my point and changing the topic, so I'm not inclined to reply. [1] https://devblogs.microsoft.com/oldnewthing/20160816-00/?p=94...
I don't know why this reply is so hostile, but I was curious what part of Windows you were referring to if not UAC, because I don't know of anything else. There is an almost comical list of bypasses in built-in AutoElevate programs that Microsoft does not triage as security bugs because as you note they don't call UAC a security feature. I think this is a rather silly deflection that users are unlikely to understand,…
Note, in particular, that there was nothing in my comment that depended on the existence of UAC. Had I written my comment before UAC even existed (say, in the XP era), it would've been exactly the same.
Yet somehow you managed to change the subject of discussion to a very specific feature UAC, a feature that was only introduced around the Vista era and which I had not even mentioned in my comment once. Then you bashed it based on a premise that you already knew was incorrect and therefore had to put in quotes, and then continued as if the point I had been making in my comment all along was to somehow endorse the use of this controversial feature I never mentioned for a purpose that it itself had not been intended. This is not a faithful representation of what I wrote.
Earlier quoted context omitted.
We have an ever changing group of about 60 engineers who need the ability to do rooty style things on about 500 different machines (very few of which are the same, so things like ansible don't work too well). While only a handful actually do, the rest need to be able to, and they're trusted to make the call. However we still want to know what's going on, and sudo fires back a message to syslog with who did it and wha…
If you take the time (once) to configure it correctly, auditd can tell you much, much more than just what commands were executed (and "hiding" the commands you ran via sudo is fairly trivial, if one is so inclined).
Either way we don't sue sudo to enforce security -- anyone could go and reboot the machine physically in any case, we use sudo so we remember what we did, or can quickly find the person who did it. Same with physical security, we don't stop people from pulling the plug, but if the plug is pulled we can see who was probably in the room at the time. You can work around it (by going in with a colleague) if you wanted to hide your tracks, but people don't hide their tracks.
Of course the other benefit of sudo is to reduce the number of terminals logged in as root, where accidents can easilly happen.
Earlier quoted context omitted.
Not rust, but the OpenBSD folks wrote doas(1). Also I am not sure how rust solves this bug, I don't think it's about memory safety is it? This is about passing -1 from a config file to a syscall, and sudo not validating the value or it being written without the understanding of what -1 means to that syscall. Nothing is mis-parsed, no buffers overflowed, etc.
It's a type confusion mistake (-1, meaning "no user ID", being the same type as an actual user ID). Idiomatic Rust would largely prevent this kind of mistake (you'd use an enum type, with a distinct value for "no user"), as long as someone first writes an idiomatic Rust wrapper for the syscalls. Obviously, if you write the Rust the same way you'd write the C, then yeah, the mistake is equally likely to happen. Rust e…
That is the most explicit way I can think of to block this with a type system. If uid_t is 32 bits, you need a type that can either contain 31 bits or no value, to prevent that 32nd bit being stuffed into the syscall somehow.
Earlier quoted context omitted.
Yeah, I started using OpenBSD's doas and it's surprising how many things expect sudo specifically.
For the most part, could you alias doas to sudo?