4 ms·

Hi jabedude! I looked at a couple of different approaches to this, and I just fell in love with the simplicity of pledge()/unveil(). The main things I like abo

by akling 7y ago

Hi jabedude! I looked at a couple of different approaches to this, and I just fell in love with the simplicity of pledge()/unveil(). The main things I like about it are: 1. The promises are baked into the programs themselves. No need to keep an outside profile in sync whenever something changes. 2. The pledge() and unveil() APIs are so simple that any program can start using them immediately. Enabling these in userspace programs has been both fun and really interesting so far. Often you’ll need to start with a wide range of promises, but you can shrink it down by reorganizing code to do more initialization up front, allowing you to drop pledges incrementally. This actually gives me the same fuzzy feeling as performance work, except instead of trying to make something take less time/space, you’re making it relinquish more capabilities. :)

smhenderson 7y ago
Hi Andreas, thanks for your work on this. I'd not heard of your project before today but I really enjoy using OpenBSD so the headline caught my eye. I'll be sure to give Serenity a try ASAP. Based on your experience so far updating user programs to use pledge and unveil; do you have any suggestions for how to go about analyzing a program up front and figure out where to spend the effort putting these into legacy code? I haven't any time to play with this on OpenBSD but I've been meaning to so any insight you can provide is most appreciated. And BTW, the screenshots of Serenity are great, really take me back to "the good ol' days"!
- akling 7y ago
  Hi smhenderson! The process so far has basically been some variant of this: 1. Describe the program to myself, and write out the promises/paths I think it will need. 2. Try it out and hit a failure 90% of the time. 3. Add the promises/paths I didn't think of. 4. Stare at it a bit. 5. Reorganize the code so I can drop more promises/paths and end up with a smaller final set. It's obviously a lot easier if you're intimately familiar with the programs you're pledging. pledge() needs are a bit easier to discover, since you can tell immediately when one is missing. unveil() needs can be trickier, since many programs handle failure to open a file and try to carry on anyway. So it takes more effort and attention to understanding file system needs. I'm still figuring this out as I go obviously. I've also gotten some good tips from brynet@ and jcs@ of OpenBSD along the way :)
  - smhenderson 7y ago
    Hi Andreas, thanks! Sounds both fun and infuriating at the same time, like a lot of low level programming I guess! :-) Thanks for the feedback, I am now looking forward to my first arrival at step 4 which is probably where I'll end up spending the bulk of my time. I appreciate the work you're doing, looks very intense and rewarding!
  - yjftsjthsd-h 7y ago
    > unveil() needs can be trickier, since many programs handle failure to open a file and try to carry on anyway. Is it possible to run strace and note failed file opens? There'll be some nice, but you could pretty easily compare against files that do actually exist and use that to make rules almost automatically, I would think?

by akling 7y ago

smhenderson 7y ago

Hi Andreas, thanks for your work on this. I'd not heard of your project before today but I really enjoy using OpenBSD so the headline caught my eye. I'll be sure to give Serenity a try ASAP. Based on your experience so far updating user programs to use pledge and unveil; do you have any suggestions for how to go about analyzing a program up front and figure out where to spend the effort putting these into legacy code? I haven't any time to play with this on OpenBSD but I've been meaning to so any insight you can provide is most appreciated. And BTW, the screenshots of Serenity are great, really take me back to "the good ol' days"!

akling 7y ago
Hi smhenderson! The process so far has basically been some variant of this: 1. Describe the program to myself, and write out the promises/paths I think it will need. 2. Try it out and hit a failure 90% of the time. 3. Add the promises/paths I didn't think of. 4. Stare at it a bit. 5. Reorganize the code so I can drop more promises/paths and end up with a smaller final set. It's obviously a lot easier if you're intimately familiar with the programs you're pledging. pledge() needs are a bit easier to discover, since you can tell immediately when one is missing. unveil() needs can be trickier, since many programs handle failure to open a file and try to carry on anyway. So it takes more effort and attention to understanding file system needs. I'm still figuring this out as I go obviously. I've also gotten some good tips from brynet@ and jcs@ of OpenBSD along the way :)
- smhenderson 7y ago
  Hi Andreas, thanks! Sounds both fun and infuriating at the same time, like a lot of low level programming I guess! :-) Thanks for the feedback, I am now looking forward to my first arrival at step 4 which is probably where I'll end up spending the bulk of my time. I appreciate the work you're doing, looks very intense and rewarding!
- yjftsjthsd-h 7y ago
  > unveil() needs can be trickier, since many programs handle failure to open a file and try to carry on anyway. Is it possible to run strace and note failed file opens? There'll be some nice, but you could pretty easily compare against files that do actually exist and use that to make rules almost automatically, I would think?