Hacker News Reader

Comment by viraptor | Hacker News Reader

While this simplification of tools is great, I'm a little disappointed that it's a system integrated app and it happened in OpenBSD fairly quietly. If it first happened in something like RH or Debian, the package would be separate from core and we would have the opportunity for the following:

- using language with more safety guarantees than C

- including seccomp (either bfp, or even just mode 1) by default

- in the announcement saying: tested with XXX, YYY, ZZZ; fuzzed with ABC, DEF

It would be a great opportunity to create a poster-child people could point to and say - this is the way we should be (re)writing secure software, these were the awesome tools used to help it. For OpenBSD the first two couldn't happen (part of base system so C; there's no seccomp support), the third could but didn't - at least not publicly (valgrind, clang-analyser, [am]san, afl, etc. could all be listed)

Maybe the next time something important is broken.

View on HN

Don't let the work of a few OpenBSD developers discourage you from creating your own file(1) implementation using your new favourite "secure" language of the week.

Everyone can write their own. Not everyone can substitute the implementation used by a large distribution and make a proper announcement people will care about. I don't understand why are you mocking language choice point though. Pretty much any language which doesn't manage memory directly would be a good choice. This utility doesn't even have big performance requirements.

Basically I'm saying that we can try very very hard to write secure code in languages which invite issues, or... try to eliminate whole classes or issues at a time. Is it such a terrible idea?

New languages and technologies come and go and you're free to use them. OpenBSD will continue to create new software while adhering to modern C coding practices, even when that means defining them.

> New languages and technologies

You mean decades-old languages like Perl and Python for example? Technologies like the ones we can finally now afford to implement - actual syscall filtering and selective capabilities dropping? Supporting utilities which only matter at development time? How do those go away?

And I wrote in the first message - OpenBSD integrates `file`, has to use C and doesn't implement seccomp. They couldn't become the poster child. But the next `file` reimplementation probably won't hit the news anymore.

People can improve the way we write software right now. But choose a project at random and they don't care or don't use what's available for free. Some promotion would be great when everyone's looking.

You have a lot more faith in the authors of memory management algorithms than I do.

Well "file" is not where I would start, as it is not really security critical for most people, although OpenBSD has good reasons.

Seccomp is almost unusable for most purposes with anything resembling tight filters as you do not really know what syscalls glibc especially will add to your program. Capsicum in FreeBSD is much more usable, and they are starting to priv-sep programs with it, they are good examples, I would look at them. Allegedly Linux will get Capsicum one day. OpenBSD has many examples of priv-sep such as openssh, just using seperate processes.

Linux is disadvantaged by not having a base system in teh same way - you can make a new "file" but how to know if anyone will use it. You can try to rewrite the Gnu tools better, but many are a horrible mess. You probably have to start a new Linux distro...

Reply on news.ycombinator.com