11–20 of 32 posts
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!
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!
Cross-unix no. But pretty much every Linux distribution supports seccomp these days.
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)
Here are the other two related commits: https://marc.info/?l=openbsd-cvs&m=143014212727213&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
From my understanding file is a pretty simple program, why does it need to care about privilege separation?
file is indeed a pretty simple program. Why allow it to do more than it needs to?
Here are the other two related commits: https://marc.info/?l=openbsd-cvs&m=143014212727213&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
then why don't they run file(1) on a private copy ?
Earlier quoted context omitted.
file is indeed a pretty simple program. Why allow it to do more than it needs to?
http://en.wikipedia.org/wiki/Small_matter_of_programming
All file needs to do is scan for some magic bytestrings, and optionally print the numbers at a handful of offsets. It currently does much more than that, which is why it's insecure and hard to fix.
Earlier quoted context omitted.
http://en.wikipedia.org/wiki/Small_matter_of_programming
I think you meant to link to http://en.wikipedia.org/wiki/Software_bloat All file needs to do is scan for some magic bytestrings, and optionally print the numbers at a handful of offsets. It currently does much more than that, which is why it's insecure and hard to fix.
If you feel the command does more than it needs to, could you call out a few examples of bloated features that you would cut?
Earlier quoted context omitted.
I think you meant to link to http://en.wikipedia.org/wiki/Software_bloat All file needs to do is scan for some magic bytestrings, and optionally print the numbers at a handful of offsets. It currently does much more than that, which is why it's insecure and hard to fix.
You say "needs" as if it's a matter of fact, but what a program needs to do is a very subjective matter. If you feel the command does more than it needs to, could you call out a few examples of bloated features that you would cut?
But I haven't seen anything to disagree with file being similarly problematic. A quote like
To sum up: If somebody uses 'file' in an unconstrained OS environment on untrusted inputs, and he gets pwnd in the result, then it's not a security problem, it's an incompetence problem - and IMO it should be discussed elsewhere.
does not suggest that the program is very well designed.
Scanning for byte strings with no possibility of security flaw is a solved problem.
Earlier quoted context omitted.
file is indeed a pretty simple program. Why allow it to do more than it needs to?
http://en.wikipedia.org/wiki/Small_matter_of_programming
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.)
From my understanding file is a pretty simple program, why does it need to care about privilege separation?
file is indeed a pretty simple program. Why allow it to do more than it needs to?