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

The first stable release of a memory safe sudo implementation

memorysafety.org

Post reply on HN
Print view View original

241–250 of 260 posts

Re: The first stable release of a memory safe sudo implementation

#241

Post by gitaarik »

charcircuit wrote: post #192
AnonC wrote: post #165

Earlier quoted context omitted.

How else would you do things as root or superuser without exposing everything? If your sudo configuration is ALL = ALL (or is a variant of this), then sudo opens everything up for use/abuse. But if you carefully construct the configuration to allow only certain commands, it’s much better than just giving out the root password to users.

>How else would you do things as root Nothing a user is supposed to do should require elevating to root to do. >it’s much better than just giving out the root password to users. This is even worse. Access control should be set up properly instead of having users assume the identity of other accounts.

And so how do you then configure a server? Like modifying the files in /etc/

Re: The first stable release of a memory safe sudo implementation

#242

Post by _8j50 »

fanf2 wrote: post #202
_8j50 wrote: post #31

IIRC, all the recent sudo vulns are logic errors, not memory safety. I mean, rewrite away but let's not pretend that there couldn't be some new bug introduced due to a misunderstanding of how something works or just a plain old mistake.

2021: https://nvd.nist.gov/vuln/detail/CVE-2021-3156 2019: https://nvd.nist.gov/vuln/detail/CVE-2019-18634

Fair point with the second one but for the first off by one is a logic error still?

Re: The first stable release of a memory safe sudo implementation

#243

Post by pbmonster »

zigzag312 wrote: post #106
pbmonster wrote: post #56

Earlier quoted context omitted.

> Regarding security, malicious actor could show you a different source code from what he distributes in a binary form. That's why hashes are published by distributors and checked by package managers, right?

That only checks that binaries are the same as what is published by distributors. It doesn't help against a malicious distributor, unless package managers also do a deterministic build themselves and verify that checksum from self-build binary matches the checksum published by a distributor.

If I'm not mistaken, many (most?) of the package managers of major Linux distributions actually build a package from source themselves in an automated process.

Otherwise, getting a package to run on different architectures would be a ton of manual labor. At least Debian certainly has that automated.

Besides the huge security risk involved in... just distributing random binaries?

Re: The first stable release of a memory safe sudo implementation

#244

Post by josephg »

arijun wrote: post #187
josephg wrote: post #35

Earlier quoted context omitted.

This would be a great use case for a capability security model. Essentially what you really want is the sudo command to acquire a temporary capability token to edit that specific file. Then run your editor and pass it the capability. (And revoke the capability when the editor process closes). It’s a pity this isn’t more straight forward to implement on Linux.

Are there no overwrite/seek bugs in Unix that could be exploited in that case? It seems to me like only using sudo for a cp command would reduce the attack surface.

I’d certainly hope not. A capability based security system in an OS is only secure if it doesn’t have bugs. Just like most security-critical software.

However, I’m not sure that Linux is capable of masquerading as a general purpose capability based operating system. I think it’s missing a bunch of APIs.

Re: The first stable release of a memory safe sudo implementation

#245

Post by charcircuit »

gitaarik wrote: post #241
charcircuit wrote: post #192

Earlier quoted context omitted.

>How else would you do things as root Nothing a user is supposed to do should require elevating to root to do. >it’s much better than just giving out the root password to users. This is even worse. Access control should be set up properly instead of having users assume the identity of other accounts.

And so how do you then configure a server? Like modifying the files in /etc/

There are several different options

1. Don't. Just include the correct configuration as part of the OS.

2. For a configuration file use a group for passing out write access to users on the system.

3. Have a daemon which handles updating configuration files based off some central source of truth which pushes changes to a fleet of servers. Programs could directly communicate with this daemon to get their configuration.

Re: The first stable release of a memory safe sudo implementation

#246

Post by zigzag312 »

pbmonster wrote: post #243
zigzag312 wrote: post #106

Earlier quoted context omitted.

That only checks that binaries are the same as what is published by distributors. It doesn't help against a malicious distributor, unless package managers also do a deterministic build themselves and verify that checksum from self-build binary matches the checksum published by a distributor.

If I'm not mistaken, many (most?) of the package managers of major Linux distributions actually build a package from source themselves in an automated process. Otherwise, getting a package to run on different architectures would be a ton of manual labor. At least Debian certainly has that automated. Besides the huge security risk involved in... just distributing random binaries?

Anyone building from source has the ability to potentially including some modifications. Unless you are able to verify that checksum published (by whoever builds the code) "matches" the source code (by reproducing the build) you cannot be sure there aren't any modifications. Published checksums are often meant only for verifying that binary you got matches the original binary. Not for verifying that it is build from specific source code.

Many Debian packages already have reproducible builds, but not everything.

From Debian wiki:

> Reproducible builds of Debian as a whole is still not a reality, though individual reproducible builds of packages are possible and being done. So while we are making very good progress, it is a stretch to say that Debian is reproducible.

https://wiki.debian.org/ReproducibleBuilds

But the point is that this has nothing to do with the type of an open source license. GPL doesn't guarantee you that a build is reproducible and MIT doesn't prevent you from having reproducible builds.

Re: The first stable release of a memory safe sudo implementation

#247

Post by zorked »

mustache_kimono wrote: post #153
zorked wrote: post #58

Earlier quoted context omitted.

Kinda? Historically there were indeed concerns about reimplementation and copyright. One of the ways that the GNU Project tried to fight claims was to reimplement the tools using dynamically-allocated memory (instead of Unix's traditional fixed-size buffers) to make sure the implementation was sufficiently different. Other ways were making the implementation Posixly correct, adding internationalization or trying to p…

> Kinda? Historically there were indeed concerns about reimplementation and copyright. Free software projects should welcome multiple implementations and interoperability, because these are the mother's milk of free software. It's frankly incoherent, given values of free software, that a reimplementation of, for example, Unix coreutils (GNU) would find fault with a reimplementation of itself (uutils). Notwithstanding…

The fact that it is free software shouldn't make things different since it's a matter of copyright law. It's fine to copy the interface - the implementation not really. There would certainly be NO problem if a close reimplementation was under the GNU GPL (as a derivive work). But a close reimplementation can't have a different license.

Re: The first stable release of a memory safe sudo implementation

#248

Post by rahen »

pjmlp wrote: post #37
fdsfsdfdsffgg wrote: post #5

> Apache-2.0+MIT vs GPL-2.0 So, you may get a memory-safe su/sudo-rs, but those who distribute it in a binary form won't be obliged to show you the source code it was built from (potentially including some modifications).

For better or worse the use of GPL is going away, even the future of Linux kernel is not guaranteed. In the realm of IoT FOSS UNIX like operating systems, all the contendants are using a mix of Apache, MIT and BSD licenses, including the ZephyrOS sponsored by the Linux Foundation. When the GPL generation is gone from the face of the Earth, it won't last long that UNIX-like OSes get another steward alternative to the…

> it won't last long that UNIX-like OSes get another steward alternative to the Linux kernel, with a more appealing license to big corps.

You mean {Free,Net,Open}BSD?

Re: The first stable release of a memory safe sudo implementation

#249

Post by pjmlp »

rahen wrote: post #248
pjmlp wrote: post #37

Earlier quoted context omitted.

For better or worse the use of GPL is going away, even the future of Linux kernel is not guaranteed. In the realm of IoT FOSS UNIX like operating systems, all the contendants are using a mix of Apache, MIT and BSD licenses, including the ZephyrOS sponsored by the Linux Foundation. When the GPL generation is gone from the face of the Earth, it won't last long that UNIX-like OSes get another steward alternative to the…

> it won't last long that UNIX-like OSes get another steward alternative to the Linux kernel, with a more appealing license to big corps. You mean {Free,Net,Open}BSD?

While those are the first ones would think of, they are not the only alternatives, specially in the embedded space.

Re: The first stable release of a memory safe sudo implementation

#250

Post by Measter »

_8j50 wrote: post #242
fanf2 wrote: post #202

Earlier quoted context omitted.

2021: https://nvd.nist.gov/vuln/detail/CVE-2021-3156 2019: https://nvd.nist.gov/vuln/detail/CVE-2019-18634

Fair point with the second one but for the first off by one is a logic error still?

It was a logic error... that led to a memory safety error, which resulted in a privilege escalation vulnerability.

Just because the source is a logic error doesn't mean the end result can't be bad when combined with a lack of memory safety.

Post reply on HN