5 ms·

> There is no reason why your PDF viewer should be able to read your SSH keys, for example. Is there any way to make use of unveil() at the command line to acc

> There is no reason why your PDF viewer should be able to read your SSH keys, for example. Is there any way to make use of unveil() at the command line to accomplish the above? To clarify, I suppose unveil() is not intended to be used that way, but will there be some sort of wrapper that allows us to restrict a third-party already-compiled program to certain directories only?

moviuro 8y ago
Slide 12: https://www.openbsd.org/papers/BeckPledgeUnveilBSDCan2018.pdf https://www.openbsd.org/papers/BeckPledgeUnveilBSDCan2018.pd... - it is one of the future goals. I really hope a similar util lands on GNU/Linux one day...
throwaway2048 8y ago
The entire point of unveil() and pledge() is tight integration with the program itself, the programmers know best what their program requires, and unveils/pledges are typically invoked AFTER all the startup junk executes (such as reading in libraries, config file dances, etc). To restrict it before the program even starts would require a huge amount of what amounts to spurious unveils once the program starts its main operating loop, and really misses the point of the abstraction its trying to create. This is exactly where approaches like selinux fail, they rely on static distro/user defined policy that can only ever be set from before the program starting, and thus must encapsulate everything the program might ever try to do. With unveil and pledge, the program itself indicates what each branch needs to do, and can much much more tightly restrict itself.
- dvfjsdhgfv 8y ago
  I don't think they fail. Usually you profile the program first, and once you set up the rules, a deviation might get blocked. If you want to define what the program is definitely not authorized to do, this is the way to go. Using the unveil() is a completely different approach that should yield less false positive and involve less hassle. There is just one caveat: you need to make sure the binary hasn't been tampered with. If someone replaced/modified it, SELinux will block unauthorized behavior, whereas counting on unveil() still working in this case might let you down.
  - Someone 8y ago
    ”If someone replaced/modified it […] counting on unveil() still working […] might let you down.” Might is an understatement. If somebody changed what you run, there’s no guarantee at all that it even still calls unveil. However, I would think chances that your system is set up such that third parties can tamper with your binaries are about equal to those that the system setup allows them to ‘tweak’ your SELinux configurations.
dilatedmind 8y ago
Would unveil and exec on the target binary work as intended?

moviuro 8y ago

Slide 12: https://www.openbsd.org/papers/BeckPledgeUnveilBSDCan2018.pdf https://www.openbsd.org/papers/BeckPledgeUnveilBSDCan2018.pd... - it is one of the future goals. I really hope a similar util lands on GNU/Linux one day...

throwaway2048 8y ago

The entire point of unveil() and pledge() is tight integration with the program itself, the programmers know best what their program requires, and unveils/pledges are typically invoked AFTER all the startup junk executes (such as reading in libraries, config file dances, etc). To restrict it before the program even starts would require a huge amount of what amounts to spurious unveils once the program starts its main operating loop, and really misses the point of the abstraction its trying to create. This is exactly where approaches like selinux fail, they rely on static distro/user defined policy that can only ever be set from before the program starting, and thus must encapsulate everything the program might ever try to do. With unveil and pledge, the program itself indicates what each branch needs to do, and can much much more tightly restrict itself.

dvfjsdhgfv 8y ago
I don't think they fail. Usually you profile the program first, and once you set up the rules, a deviation might get blocked. If you want to define what the program is definitely not authorized to do, this is the way to go. Using the unveil() is a completely different approach that should yield less false positive and involve less hassle. There is just one caveat: you need to make sure the binary hasn't been tampered with. If someone replaced/modified it, SELinux will block unauthorized behavior, whereas counting on unveil() still working in this case might let you down.
- Someone 8y ago
  ”If someone replaced/modified it […] counting on unveil() still working […] might let you down.” Might is an understatement. If somebody changed what you run, there’s no guarantee at all that it even still calls unveil. However, I would think chances that your system is set up such that third parties can tamper with your binaries are about equal to those that the system setup allows them to ‘tweak’ your SELinux configurations.

dilatedmind 8y ago

Would unveil and exec on the target binary work as intended?