Hacker News Reader

Comment by thr0wnawaytod4y | Hacker News Reader

but if sudo was written in java we'd have other problems ;)

Yes, I agree. I did not mean to imply that literally any other language would have been better for sudo, which I see is a viable reading of my original post. Go, for instance, would be a terrible choice, because the way the runtime deeply assumes you're running in a multithread environment, even before it gets to your "main" function, means that exactly the sort of UNIX hackery sudo is designed to do is effectively impossible. I have a system myself that is otherwise entirely in Go, but we have a very small C-based wrapper whose job it is to be setuid, open a few files with the escalated privileges, do some user verification, then change its uid and gid and exec the "real" Go program, because Go just can't do those things.

Dynamically typed languages as a whole would be a bad idea.

Java's startup time for such a small executable would be a problem.

I'm just saying this problem is unique to C, and in my opinion, sufficiently endemic to security software to disqualify it entirely.

Mind you, you might well end up at Rust in the end anyhow. Perhaps D. It isn't necessarily a long list for a sudo replacement. But...

C delenda est.

In a way it is kind of an ironic tragedy, that the followers of C church worship UNIX and Plan 9, while ignoring the end station from the priesters, Inferno and Limbo, where C was confined to the minimal trust base of the kernel and a couple of drivers, with everything else in userspace mostly written in Limbo.

Here is "runas" in Limbo, https://bitbucket.org/inferno-os/inferno-os/src/master/appl/...

Do you know one of the reasons why Multics had a better security score than UNIX on DoD assement?

PL/I does bounds checking by default.

For reals. The fact that C toolchains have never even offered a bullet-proof bounds-checked (no UB) mode, no matter what the slowdown, boggles the mind. For something like sudo, literally running 100x slower would not be an issue. Its highest priority should be security.

100x slower would definitely be an issue. I am prompted for my sudo password probably 30x daily.

How long does sudo take to load on your system. Multiply that by 3000, is it really a noticeable number?

Seems to float around 0.005s (using "time sudo -k" to avoid timing user input), so yeah, x3000 = 15 seconds. Very noticeable.

Or even the x100 from (G)GP, that's a half second. Sometimes spiking to a full second.

I am seeing an average of 0.0008 over 100 runs on Linux (i.e. less than a millisecond).

Careful, admiral Hopper will give you an earful if you disrespect milliseconds.

I have once seen a proposal to make any sudo call wait for 10 seconds before doing anything so that the person running it has a moment to thing about what they just did do (and have ~10 seconds to ^C cancel it).

The person arguing also brought up that normally anything needing sudo should be automatized so that should be fine.

I'm not doing enough system administration to judge if that is a sane idea or not ;=)

That might be a reasonable idea but the time probably shouldn't be imposed by performance constraints.

Does it say somewhere that non-neteork-io PAM modules are supposed to be constant time?

  def add_noise(t=10):
    time.sleep(t-1)
    time.sleep(
      uniformrandom(min=0,max=1))

Constant time: https://en.wikipedia.org/wiki/Time_complexity#Constant_time

(Re: Short, DES passwords https://en.wikipedia.org/wiki/Triple_DES :

> A CVE released in 2016, CVE-2016-2183 disclosed a major security vulnerability in DES and 3DES encryption algorithms. This CVE, combined with the inadequate key size of DES and 3DES, NIST has deprecated DES and 3DES for new applications in 2017, and for all applications by the end of 2023.[1] It has been replaced with the more secure, more robust AES.

Except for PQ. For PQ in 2022: https://news.ycombinator.com/item?id=32760170 :

> NIST PQ algos are only just now announced: https://news.ycombinator.com/item?id=32281357 : Kyber, NTRU, {FIPS-140-3}? [TLS1.4/2.0?]

I'm not sure I follow this comment.

Adding a random amount of time seems like a reasonable thing to do.

Not sure what the links are all about, or the discussion of time complexity... I mean, there isn't an "input size" to talk about big-O scaling anyway, in the case of sudo.

Should the time to complete the (single-character) password-hashing/key-strengthening routine vary in relation to any aspect of the input ?

Timing attacks > Avoidance https://en.wikipedia.org/wiki/Timing_attack

That assumes that sudo the executable taking longer would linearly increase the time when in fact your OS loaded the exe into memory, created a process, allocated memory and let it go. A significant amount of time was just that, nothing related to the program’s job.

"time /bin/false" and "time /bin/true" consistently give me 0.001s though

“ When used alone, the -k (kill) option to sudo invalidates the user's cached credentials.”

IO wouldn’t get slower though, and likely that takes the majority of its running time.

Ah, fair enough, that's a bit high of a multiplier.

I just checked, and on the machine I'm sitting at 100x slower would mean it took 0.1s of CPU time.

Come on, wtf? Your computer can literally emulate another architecture in real time and you think sudo 100x slower would be humanly sensible? Computers literally wait eons for human inputs in the majority of times.

I assume you actually think that sudo takes the time it does, but you just likely entered your password wrong and are made to wait deliberately through a sleep. Are we really that bad at ball parking code execution times?!

I have come to conclude that WG14 literally doesn't care about security, for them C should stay as a kind of portable macro assembler with amenities, and the same security guarantees as writing raw Assembly code.

Even the pseudo secure Annex K, requires separate arguments for actual length and max buffer length, thus defeating the purpose of being library functions for secure code.

Just having one of the many libraries that provide secure strings and vector handling, so that libraries can rely on a common vocabulary types would be an improvement.

Like what? It would be written once correctly and work as is intended pretty much forever.

Reply on news.ycombinator.com