

OpenBSD's new file(1) is now priv-separated - nayden
http://marc.info/?l=openbsd-cvs&m=143014276127454&w=2

======
brynet
Here are the other two related commits:

[https://marc.info/?l=openbsd-
cvs&m=143014212727213&w=2](https://marc.info/?l=openbsd-
cvs&m=143014212727213&w=2)

[https://marc.info/?l=openbsd-
cvs&m=143014250427343&w=2](https://marc.info/?l=openbsd-
cvs&m=143014250427343&w=2)

There are unfortunately a lot of people who depend on file(1); and many of
them also run it as root.

Also previous HN discussion:
[https://news.ycombinator.com/item?id=9439778](https://news.ycombinator.com/item?id=9439778)

~~~
SixSigma
then why don't they run file(1) on a private copy ?

~~~
brynet
OpenBSD has yet to successfully program human behaviour.

------
CJefferson
How easy is privilege separation nowadays? Are there any cross-platform
libraries (well, cross-unix at least)?

Most programs I write I would be happy, fairly soon after startup, to drop to
"just read and write handles I've already got". It would make me feel much
better about my badly written parsers!

~~~
viraptor
Cross-unix no. But pretty much every Linux distribution supports seccomp these
days.

~~~
brynet
Privilege separation is achievable by using separate unprivileged users. If
root is required, fork and drop root and then use something like OpenBSD's
imsg(3) API to properly pass resources between the privileged parent and
unprivileged child processes.

If you want to go a step further and sandbox, use setrlimit(2)/chroot(2). And
if it's appropriate, use technologies like systrace(4) or Linux seccomp(2).

There are many examples of this in OpenBSD's base system, including some most
people don't know about.. like tcpdump(8)

------
msl09
From my understanding file is a pretty simple program, why does it need to
care about privilege separation?

~~~
DasIch
file is indeed a pretty simple program. Why allow it to do more than it needs
to?

~~~
raldi
[http://en.wikipedia.org/wiki/Small_matter_of_programming](http://en.wikipedia.org/wiki/Small_matter_of_programming)

~~~
IvyMike
I think DasIch is saying "why allow file(1) to open sockets, write to
arbitrary files, and run external programs"?

Given the correct input, at least a month ago, it could do all of those
things.

(I am not sure that attempting to enforce this _within_ the file(1) binary is
optimal... after all, even though the attack surface is much reduced, file(1)
could _still_ have a bug somewhere prior to the sandboxing. If you could do a
"chpriv -write_to_disk -socket -run_external_program /bin/file" that the OS
would enforce, that would be cool. Someone should create that.)

~~~
raldi
_> why allow file() to open sockets_

If by "open sockets" you mean open existing sockets in read-only mode, it's so
that it can identify them as sockets. If by "open sockets" you mean create new
sockets, I don't think it does do that:

[https://github.com/threatstack/libmagic/search?utf8=%E2%9C%9...](https://github.com/threatstack/libmagic/search?utf8=%E2%9C%93&q=socket)

 _> write to arbitrary files_

It appears it only does this if running on OS/2 and investigating what's
inside a compressed file. Under these conditions, a temporary file is
necessary for platform-specific reasons:

[https://github.com/threatstack/libmagic/blob/3dea7072b8d7e92...](https://github.com/threatstack/libmagic/blob/3dea7072b8d7e927e6f9b1ef381a70271376f322/src/file.h#L466)

[https://github.com/threatstack/libmagic/blob/3dea7072b8d7e92...](https://github.com/threatstack/libmagic/blob/3dea7072b8d7e927e6f9b1ef381a70271376f322/src/apptype.c#L68)

It also writes to a non-arbitrary mmapped file (the magic database), because
that's how such databases work; you query them by writing to them in a
particular way:

[https://github.com/threatstack/libmagic/blob/3dea7072b8d7e92...](https://github.com/threatstack/libmagic/blob/3dea7072b8d7e927e6f9b1ef381a70271376f322/src/apprentice.c#L2782)

 _> run external programs_

I can't find any examples where it does that. Do you know of any?

~~~
IvyMike
"It may be possible for such an attacker to execute arbitrary code with the
privileges of the user running file(1)."

This is what I am saying...given the right input, file(1) could do anything
and everything. Yes, it's only due to a bug in file(1), but still that's kind
of ridiculous.

We have all sorts of things in place to protect against other bugs (for
example, segmentation faults), and there's 27 years of evidence that we need
some more help.

~~~
bandrami
_Yes, it 's only due to a bug in file(1), but still that's kind of ridiculous_

I point again to:

[http://en.wikipedia.org/wiki/Halting_problem](http://en.wikipedia.org/wiki/Halting_problem)

If you are reading in from a file, and you make decisions that are complex
enough to be S- and K- combinators (or a concept of "if" and "jump", or some
other minimal set), then you have given an attacker a Turing machine.

~~~
IvyMike
I agree.

But what I'm saying is that the Turing machine should not be connected to a
gun. And being hooked up to an idle gun should not be the default for every
program.

------
viraptor
Separation is done. 1/3 points done:
[https://news.ycombinator.com/item?id=9441262](https://news.ycombinator.com/item?id=9441262)

I didn't realise openbsd had a seccomp equivalent, but I'm happy it does! (And
it did make the news again)

~~~
bandrami
Systrace was added to the base system 10 or 11 years ago (3.6, IIRC), but
there was some hesitation among some key team members to use it widely (the
argument being that privilege separation utilities themselves will almost
always have security problems). That ship seems to have sailed, though, in
more recent years.

~~~
jquast
I think the lack of implementation was that were vulnerabilities in design
that I don't think were ever resolved, it simply can't work as the only line
of defense.
[http://undeadly.org/cgi?action=article&sid=20070809201304](http://undeadly.org/cgi?action=article&sid=20070809201304)

It's too bad, I think system calls are a very good place to apply security
policies. I think the issue is that one can modify the memory structures
pointed to by a system call after it has been "approved" by systrace policy,
but before the kernel acts on it. While the ownership of such data structures
are in userspace, its perfectly fine to modify such regions.

It's too bad, I think its possibly the most straight-forward approach compared
to SELinux or MAC

