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

251–260 of 260 posts

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

#251

Post by zorked »

zorked wrote: post #247
mustache_kimono wrote: post #153

Earlier quoted context omitted.

> 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.

*derivative work

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

#252

Post by mustache_kimono »

zorked wrote: post #247
mustache_kimono wrote: post #153

Earlier quoted context omitted.

> 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.

This was a discussion of the philosophical/meta/attitudinal issues, and why this is kinda a bizarre attitude for a free software project to hold.

Legally -- implicit in your comment are unstated assumptions about what is copied from the implementation. Suffice to say -- I disagree that a so-called "clean room" implementation is always required re: software published on the internet, or that the act of simply reading GPL code taints one forever, re: that code. The reason why is the reason why reading a book does not taint one forever and prevent one from writing one's own book -- "You should have used a while loop instead of a for loop here, now you're going to copyright prison." See, and pay close attention to the "Merger Doctrine": https://en.wikipedia.org/wiki/Idea–expression_distinction

It's my view that copyright is a rather weak IP protection, and GPL-type advocates have misconstrued the law of copyright for years, especially "derivative works". Mostly because they've been misinformed about the law by mendacious FOSS leadership cough like the FSF and SFC.

Now I'd agree with you, if there is something especially clever/creative about the GNU implementation that the reimplementation copies, that might be an issue, but again, even then, it seems especially rich for a reimplementation to find fault with another reimplementation.

You might also take a look at another comment of mine re: some aspects of this matter: https://news.ycombinator.com/item?id=38164958

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

#253

Post by chlorion »

bunderbunder wrote: post #228
chlorion wrote: post #185

Earlier quoted context omitted.

It's true that it doesn't eliminate all bugs in general, but it can completely eliminate buffer overflows for example. There is no excuse to not at least have bounds checking. This is one of the most basic memory safety problems and it's trivial to prevent. Just preventing this small issue will prevent a non-trivial fraction of bugs. I don't have sudo's bug list on hand but I wouldn't be surprised if 25% or more are…

> You can't switch them off. https://doc.rust-lang.org/book/ch19-01-unsafe-rust.html

From this link:

>It’s important to understand that unsafe doesn’t turn off the borrow checker or disable any other of Rust’s safety checks: if you use a reference in unsafe code, it will still be checked.

Unsafe rust basically just lets you use raw pointers, mutate static variables, use C-style unions, and do FFI calls, but otherwise it's exactly the same, and the safety checks are not in any way disabled.

The main thing is that pointers let you access whatever memory you want, and borrow checking the pointer value itself doesn't prevent this.

I don't think I would describe this as "switching them off", I would describe it as, "using raw pointers" or something along those lines.

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

#254

Post by unaindz »

happymellon wrote: post #12
jacquesm wrote: post #11

Earlier quoted context omitted.

I still run into trouble on a fairly regular basis on account of systemd. Especially the log files continue to cause all kinds of issues.

What issues do you run into with the log files? I have plenty of ideological problems with the design of the logs, but not actually ran into problems in the real world.

I get hit by this constantly: https://github.com/systemd/systemd/issues/2460

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

#255

Post by trealira »

bunderbunder wrote: post #100
nolok wrote: post #67

Earlier quoted context omitted.

In memory safety ? Yes, the language is much better at being safe by default. But it does nothing for logics bugs. The thing is, replacing from C (sudo or anything else), the number of exploit due to null pointer or buffer abuse or ... represent easily 50% of it.

This gets said a lot, but I am coming to believe that the case is overstated. For two reasons: 1. Valgrind exists. It's not perfect, but it does arguably do a pretty good job as long as you're writing modern C. The biggest gap I'm aware of is that it can't really help you with global pre-allocated buffers. But I don't think that any language or tool can effectively protect you from information leakage if you're doing…

> It's not perfect, but it does arguably do a pretty good job as long as you're writing modern C.

There's no such thing as modern C. C code that's written neatly and meticulously looks the same today as it did 30 or 40 years ago, except for language changes such as the move from K&R declarations to function prototypes. C the language hasn't changed since 1989 except for minor things like mixed functions and declarations, the introduction of the long long type, restrict pointers, designated initializers, compound literals, and threads being in the standard library.

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

#256

Post by stouset »

happymellon wrote: post #221
stouset wrote: post #215

Earlier quoted context omitted.

journalctl -f On the flip side, now you get structured logging, efficiently-searchable logs over any of those fields, the ability to easily aggregate logs from multiple machines, the ability to accurately iterate over logs in processes without missing entries, and on and on and on. Logs as a database is wildly superior to logs as a plain text file, with virtually the only downside being that you need a specific progr…

> the only downside being that you need a specific program to tail them. The journal can output to text files as well! But this is exactly it, my only issue is the ideological one that there is no spec for the database. The implementation is the specification, so the only true way of building a reader of logs is to implement the journal. There are attempts to document the layout but if there is any difference then yo…

I can totally agree with you there!

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

#257

Post by slikrick »

Calzifer wrote: post #159
sgerenser wrote: post #140

Earlier quoted context omitted.

It can eliminate many bugs, but it certainly wouldn’t eliminate all bugs. During implementation they realized they were not implementing sudo’s (undocumented) feature of failing to run if the sudoers file is world-writable: https://ferrous-systems.com/blog/testing-sudo-rs/ . Of course they did find and fix the bug, but in general Rust isn’t going to protect you from bugs like this that are essentially logic errors.

That is documented. Since the mercurial web interface isn't very nice to use I picked a random version. sudo 1.8.6 from 2012 writes in the man page "The sudoers file must not be world-writable,". https://www.sudo.ws/repos/sudo/file/SUDO_1_8_6/doc/sudoers.m... This is also a very common behaviour for security sensitive applications to check config file permissions. Another example I remember are ssh private keys. I mi…

I might be too harsh, but it is not so trustworthy that they found bugs within the original sudo after less than a year of effort. those other devs had over 40 years to find it

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

#259

Post by slikrick »

zorked wrote: post #251
zorked wrote: post #247

Earlier quoted context omitted.

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.

*derivative work

a reimplementation that copies the interface has no need to copy the license. GPL people just get scared because they know their license can't prevent people from rewriting their own software (of course, such an idea is ridiculous).

the GPL is not a perfect license, there is no such thing.

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

#260

Post by slikrick »

NegativeK wrote: post #143
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…

How would they be able to drop the GPL from the Linux kernel?

by having the Linux kernel be a sub part of a larger system. literally look at WSL2
Post reply on HN