On Tue, Jun 15, 2021 at 04:33:19PM +0000, [email protected] wrote: > >> And I am not letting someone write to the filesystem. Yet, they can > >> bypass that easily. `unveil("/", "rx")` gives a false illusion of > >> security, which can even trip up OpenBSD maintainers (more below). > > > > That statement has a precise meaning, so I disagree. The unveil manual > > page does not contain the word "security" even once, so you are the one > > jumping to conclusions. > > https://www.openbsd.org/papers/BeckPledgeUnveilBSDCan2018.pdf > This presentation does, though. Man pages aren't the only source of > information, and in fact this exact presentation was the place where > I've found out what unveil is. It's on the official domain, so I've > assumed that it was a trustworthy source - I guess not? Did a hacker > put it there?
You are just trolling around. Sorry but a presentation of a brand new feature is not documentation. It shows the state in 2018 and since then a lot has changed. That presentation is actually very clear that some ideas are dreams and that stuff will change. > > To generate a specific effect, the tool has to be used correctly. > Which, in it's current state, is confusing even for people with in-depth > knowledge of OpenBSD. If a maintainer can't use it correctly, what about > us "mere mortals" who have never looked at the kernel's source? The problem is that you decided that it should work in a way it does not and are unable to accept that fact. Nobody mentioned that unveil is trivial and can be used for all the cases. It is not. It is much simpler than other systems though and because of this a lot of code in OpenBSD uses unveil() but not all code uses it either. The main goal was to build something that works for a few important applications but it is not a universal tool because it would be so complex that neither "mere mortals" nor OpenBSD developers would be able to use it. > > I guess you don't know how shared executables work. > hm. That's possible, I'm not omnipotent. I've tried running a few > dynamically linked binaries under an OpenBSD vm with all mounts set > to read-only and they've seemed to work fine though. > > > > The behaviour isn't documented, because the behaviour you want is > > non-sensical. It simply does not work, because of shared libraries, > > and other things that programs do upon initialization. > *because YOU think it's non-sensical. Again, it's was literally used > in this exact way by other OpenBSD maintainers. > Also, what do you exactly mean by "other things"? If it's a program > e.g. writing to a log file, or to a lock file, or to whatever, and > I'm exec'ing that exact program, I can just give it access to that. > Principle of least privilege. If it only needs access to its lock file, > why should I give it access to my ssh keys? This is not what unveil is about. It is not a multi-application sandbox. It was built to remove access to ssh keys for the running application because the developer knows how the program works. Executing a new program resets the unveil since there is no way to know for the calling application what unveils are required to run the next command. > > Rather than arguing with Claudio and I, [...] > I wasn't arguing with Claudio. They were nice, they treated me like an > equal. > > why don't you TRY to change the kernel do so so, and learn the > > consequences. > That's my plan, actually! I'm probably going to use plan9 instead, it > has some very nice features which could aid me in that. In fact, > that's why I've asked the next question: > > >> Out of curiosity, have there been any discussion on this? I tried > >> looking around on the mailing list archives, but I haven't found > >> anything regarding this. > > Terribly sorry you didn't get what you aren't owed. > This one! Thanks for your apologies. I still hope that Claudio replies, > I've asked them nicely and they seem like quite a nice person too. > Seeing what went wrong for y'all would save me quite some time. > Cooperation is what FOSS is about, after all. We don't write long design documents that then fail to be implemented. It took multiple tries to get unveil() off the ground. realpath(3) is a good example that took many tries to figure out. During this time it was also realized that keeping unveil over exec is kind of impossible without weakening unveil(). You can't restrict access and still allow every program to run. -- :wq Claudio
