Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Sudo-rs' first security audit

ferrous-systems.com

Post reply on HN
Print view View original

21–30 of 63 posts

Re: Sudo-rs' first security audit

#21

Post by cedws »

technion wrote: post #10
eep_social wrote: post #3

Earlier quoted context omitted.

Which parts are you thinking of removing? The goal is “to build a drop-in replacement for all common use cases of sudo” so the doas comparison doesn’t really follow. The fabulous article mentions that, “sudo-rs only has 3 dependencies in its dependency graph” so maybe they could trade loc for deps but that doesn’t seem wise to me. The audit found one moderate path traversal vulnerability which was also present in og…

I think the one moderate vulnerability is an example of this. I have serious doubts about anyone having wanted to use that remove timestamps parameter in 2023. I'd be surprised if many people know it exists. I more surprised an os would let you make a user with "../../" in the name though. I'd bet a heap of things would break. A while back I saw a guy name his windows desktop with an emoji and all sorts of software f…

>A while back I saw a guy name his windows desktop with an emoji and all sorts of software fell over.

Presumably all of it was written in languages built on old assumptions that a single character is one byte.

Re: Sudo-rs' first security audit

#22

Post by 3c6bYDXLMj »

comex wrote: post #16

> Description: The cargo release build does not strip symbols, so they will be included in the final binary. (..) Impact: Since the code is open source, there is not much information to be gained, but removing these symbols might make reverse engineering of the binary harder. What a ridiculous finding. I can try to steelman the argument. Sure, maybe "reverse engineering of the binary" is useless most of the time for…

Come off it. That’s what the severity rating is for. Anyone used to reading these sorts of reports comes to expect these things. And someone saying “all you have to do, is simply…” doesn’t change the fact that there’s suddenly more effort involved.

Re: Sudo-rs' first security audit

#23

Post by cedws »

eep_social wrote: post #18
cedws wrote: post #15

Earlier quoted context omitted.

>Removing the need entirely (as they are both conceptually broken) seems like a huge lift that’s probably not feasible without fundamental changes A sort of workaround is that you can log in as the desired user from a TTY. Of course, this gets tricky if you don't have physical access or a remote serial connection. And you probably wouldn't want to log in as root over SSH. I don't have real solutions in mind but it's…

Aye, but then we are (I think) sharing credentials so we can both log in as the user with specific (read: elevated) permissions, and we lose any ability to know who the “real” person-user is on top. So it’s a different problem and we’re starting to talk about threat models and such..

> we lose any ability to know who the “real” person-user is on top

It's a complex topic probably best suited for discussion elsewhere, but do we even need to discern that anymore? Statistically most Linux systems running now are single-seat (as in, one real user).

A big corp with thousands of servers and employees might want to know this stuff for audit logging, but if employees have root access, they can already fake everything at ring 3. Big corps use security software that do that stuff in ring 0.

Re: Sudo-rs' first security audit

#24

Post by inferiorhuman »

codetrotter wrote: post #4
eep_social wrote: post #3

Earlier quoted context omitted.

Which parts are you thinking of removing? The goal is “to build a drop-in replacement for all common use cases of sudo” so the doas comparison doesn’t really follow. The fabulous article mentions that, “sudo-rs only has 3 dependencies in its dependency graph” so maybe they could trade loc for deps but that doesn’t seem wise to me. The audit found one moderate path traversal vulnerability which was also present in og…

> the doas comparison doesn’t really follow The real question is, do you really need everything that sudo can do? Or would doas be sufficient? On my FreeBSD servers, I install doas instead of sudo, and I have never once found myself missing any features in spite of having completely replaced sudo with doas on my FreeBSD servers. Replaced as in, I no longer even have sudo installed on my FreeBSD servers. I switched fr…

On FreeBSD the only thing I miss from sudo is the credential caching. I believe opendoas uses the same fairly portable method that sudo does. doas uses an OpenBSD-specific API.

Re: Sudo-rs' first security audit

#25

Post by e12e »

codetrotter wrote: post #4
eep_social wrote: post #3

Earlier quoted context omitted.

Which parts are you thinking of removing? The goal is “to build a drop-in replacement for all common use cases of sudo” so the doas comparison doesn’t really follow. The fabulous article mentions that, “sudo-rs only has 3 dependencies in its dependency graph” so maybe they could trade loc for deps but that doesn’t seem wise to me. The audit found one moderate path traversal vulnerability which was also present in og…

> the doas comparison doesn’t really follow The real question is, do you really need everything that sudo can do? Or would doas be sufficient? On my FreeBSD servers, I install doas instead of sudo, and I have never once found myself missing any features in spite of having completely replaced sudo with doas on my FreeBSD servers. Replaced as in, I no longer even have sudo installed on my FreeBSD servers. I switched fr…

Users and groups (auth/autz) via kerberos/ldap/active directory? Radius?

Not something "most users" would need - and probably handled in Pam, not sudo - but it's one thing that comes to mind.

Re: Sudo-rs' first security audit

#26

Post by 0xbadcafebee »

cedws wrote: post #2

I just ran tokei in the sudo-rs repository and there's over 28,000 lines of code not including whitespace. The Rust rewrite is a good step forward but we should really be asking ourselves if we need all this complexity in something so critical. OpenBSD's doas is 108 lines of C. sudo and doas are not equivalent in functionality, but it shows how simple things can really be. https://github.com/openbsd/src/blob/master/d…

You can live a really simple life if you just stop using computers.

Simple isn't always better.

Re: Sudo-rs' first security audit

#27

Post by e12e »

cedws wrote: post #23
eep_social wrote: post #18

Earlier quoted context omitted.

Aye, but then we are (I think) sharing credentials so we can both log in as the user with specific (read: elevated) permissions, and we lose any ability to know who the “real” person-user is on top. So it’s a different problem and we’re starting to talk about threat models and such..

> we lose any ability to know who the “real” person-user is on top It's a complex topic probably best suited for discussion elsewhere, but do we even need to discern that anymore? Statistically most Linux systems running now are single-seat (as in, one real user). A big corp with thousands of servers and employees might want to know this stuff for audit logging, but if employees have root access, they can already fak…

> if employees have root access

The main usecase of sudo over su (or suid binaries) is limited access (clear/re-run the mail queue - not reconfigure the mail daemon)

Re: Sudo-rs' first security audit

#28

Post by 0xbadcafebee » 

  CLN-001: relative path traversal vulnerability (moderate)

  During the audit, it came to light that the original sudo implementation was also affected by this issue, although with a lower security severity due to their use of the openat function.
I thought Rust was secure? How is it possible to write a program in Rust and still have the same security vulnerabilities, and actually be higher severity?

It's almost as if changing to an entirely new programming language and ecosystem isn't enough to make a secure application, and that you still have to try hard to secure it, regardless of the language.

How interesting.

Re: Sudo-rs' first security audit

#29

Post by trclst »

biorach wrote: post #17
cedws wrote: post #2

I just ran tokei in the sudo-rs repository and there's over 28,000 lines of code not including whitespace. The Rust rewrite is a good step forward but we should really be asking ourselves if we need all this complexity in something so critical. OpenBSD's doas is 108 lines of C. sudo and doas are not equivalent in functionality, but it shows how simple things can really be. https://github.com/openbsd/src/blob/master/d…

> we should really be asking ourselves if we need all this complexity in something so critical What is all the complexity? What is all the extra functionality that sudo offers?

sudoedit would be an example.

Re: Sudo-rs' first security audit

#30

Post by Karellen »

biorach wrote: post #17
cedws wrote: post #2

I just ran tokei in the sudo-rs repository and there's over 28,000 lines of code not including whitespace. The Rust rewrite is a good step forward but we should really be asking ourselves if we need all this complexity in something so critical. OpenBSD's doas is 108 lines of C. sudo and doas are not equivalent in functionality, but it shows how simple things can really be. https://github.com/openbsd/src/blob/master/d…

> we should really be asking ourselves if we need all this complexity in something so critical What is all the complexity? What is all the extra functionality that sudo offers?

The ability to specify limited groups of commands that a subset of users can run, among other things.

The "Examples" section of the sudoers(5) man page is probably a good place to start to get an idea of the sorts of ways it can be configured

https://manpages.debian.org/bookworm/sudo/sudoers.5.en.html#...

Post reply on HN