4 ms·

There are many inherent problems with utilities like file(1), however, if people are going to continue using them then we should try to make the best implementa

by brynet 11y ago

There are many inherent problems with utilities like file(1), however, if people are going to continue using them then we should try to make the best implementation possible. This new implementation was created from scratch, carefully, with modern coding practices by a very proficient programmer.

deleted 11y ago
[deleted]
_delirium 11y ago
I do think a cleaner, more careful file(1) implementation is a step in the right direction. But it's still a bit unnerving to me that a bug in a utility like file(1), which needs to do nothing but read a file and output text to stdout, could possibly do things like overwrite other files, write to the network, etc., even in the presence of parsing bugs and a maliciously crafted file. A parsing bug in a utility that does nothing but read files and parse them should not be able to do anything worse than force a misparse! The file(1) binary simply does not need to have permission to do things like write to the network or disk. This seems like a shortcoming of the traditional Unix permissions model. A promising direction imo is the more fine-grained permission model of Solaris/Illumos, which FreeBSD's Capsicum project also aims in the direction of.
- BruceM 11y ago
  Or object capability systems in general ... like the material at http://erights.org/ http://erights.org/ and the security kernel work from long long ago: http://mumble.net/~jar/pubs/secureos/ http://mumble.net/~jar/pubs/secureos/ and http://mumble.net/~jar/pubs/secureos/secureos.html http://mumble.net/~jar/pubs/secureos/secureos.html
- geofft 11y ago
  While capability systems are totally awesome, for this sort of application, you don't really need it. Open the target file read-only, open the magic database read-only, keep stdout open, and then even something as restrictive as Linux's seccomp mode 1 sandbox (read(2), write(2), exit(2), nothing else) should be enough to let you print out an answer.
- rwmj 11y ago
  SELinux does exactly this already.
- benmmurphy 11y ago
  I thought this was basically apparmour: https://wiki.ubuntu.com/AppArmor https://wiki.ubuntu.com/AppArmor
geofft 11y ago
> This new implementation was created from scratch, carefully, with modern coding practices by a very proficient programmer. Cool. What happens 10 years from now, when we've wanted all the missing features back, and when writing C code (let alone C code without tests) to run on untrusted input is no longer "modern coding practices" but firmly legacy? This seems like a great way to have a version of file(1) that works great in 2015, on the subset of filetypes that are in-scope for the initial version, on this version of OpenBSD, but I'd like to know how it becomes sustainable.
- brynet 11y ago
  Nobody is saying this is a perfect implementation, however, it has been written in-line with existing best coding practices that any OpenBSD developer should be comfortable with, and hence maintainable until it is deemed not to be. If everyone suddenly stopped depending on file(1), then it would happily be removed from the tree.
  - geofft 11y ago
    Yes, to be clear, this is a huge improvement. But it's sort of like living in a world where modern medicine has been discovered, and celebrating that one city has started moving away from leeching to treat fevers, while every other city is still practicing it, and that one city still uses leeching to treat many other diseases. Strictly speaking, it is an improvement, but....
    - jblow 11y ago
      "This solution isn't perfect therefore we shouldn't do it"?
      - geofft 11y ago
        That doesn't really seem like the right response to a culture of bloodletting, does it? I was going for, let's quit bloodletting, but let's also not celebrate how we're occasionally no longer bloodletting, because it's still embarrassing how far behind modern medicine we are.

by brynet 11y ago

deleted 11y ago

[deleted]

_delirium 11y ago

I do think a cleaner, more careful file(1) implementation is a step in the right direction. But it's still a bit unnerving to me that a bug in a utility like file(1), which needs to do nothing but read a file and output text to stdout, could possibly do things like overwrite other files, write to the network, etc., even in the presence of parsing bugs and a maliciously crafted file. A parsing bug in a utility that does nothing but read files and parse them should not be able to do anything worse than force a misparse! The file(1) binary simply does not need to have permission to do things like write to the network or disk. This seems like a shortcoming of the traditional Unix permissions model. A promising direction imo is the more fine-grained permission model of Solaris/Illumos, which FreeBSD's Capsicum project also aims in the direction of.

BruceM 11y ago
Or object capability systems in general ... like the material at http://erights.org/ http://erights.org/ and the security kernel work from long long ago: http://mumble.net/~jar/pubs/secureos/ http://mumble.net/~jar/pubs/secureos/ and http://mumble.net/~jar/pubs/secureos/secureos.html http://mumble.net/~jar/pubs/secureos/secureos.html
geofft 11y ago
While capability systems are totally awesome, for this sort of application, you don't really need it. Open the target file read-only, open the magic database read-only, keep stdout open, and then even something as restrictive as Linux's seccomp mode 1 sandbox (read(2), write(2), exit(2), nothing else) should be enough to let you print out an answer.
rwmj 11y ago
SELinux does exactly this already.
benmmurphy 11y ago
I thought this was basically apparmour: https://wiki.ubuntu.com/AppArmor https://wiki.ubuntu.com/AppArmor

geofft 11y ago

> This new implementation was created from scratch, carefully, with modern coding practices by a very proficient programmer. Cool. What happens 10 years from now, when we've wanted all the missing features back, and when writing C code (let alone C code without tests) to run on untrusted input is no longer "modern coding practices" but firmly legacy? This seems like a great way to have a version of file(1) that works great in 2015, on the subset of filetypes that are in-scope for the initial version, on this version of OpenBSD, but I'd like to know how it becomes sustainable.

brynet 11y ago
Nobody is saying this is a perfect implementation, however, it has been written in-line with existing best coding practices that any OpenBSD developer should be comfortable with, and hence maintainable until it is deemed not to be. If everyone suddenly stopped depending on file(1), then it would happily be removed from the tree.
- geofft 11y ago
  Yes, to be clear, this is a huge improvement. But it's sort of like living in a world where modern medicine has been discovered, and celebrating that one city has started moving away from leeching to treat fevers, while every other city is still practicing it, and that one city still uses leeching to treat many other diseases. Strictly speaking, it is an improvement, but....
  - jblow 11y ago
    "This solution isn't perfect therefore we shouldn't do it"?
    - geofft 11y ago
      That doesn't really seem like the right response to a culture of bloodletting, does it? I was going for, let's quit bloodletting, but let's also not celebrate how we're occasionally no longer bloodletting, because it's still embarrassing how far behind modern medicine we are.