Re: [dev] pledge(2) patches

> This way, we can call it easily in the code without troubles. > I admittedly am a huge supporter of pledge() and would be happy Then send the patch to the maintainer of the OpenBSD port. Regards,

Re: [dev] pledge(2) patches

> Terminals accept arbitrary input, so pledge support could be a very desirable > and well-suited feature. Then add the lines yourself. Regards,

Re: [dev] pledge(2) patches

On Mon, Jun 06, 2016 at 02:39:04PM +0200, FRIGN wrote: > What it all brings up is the issue of IPC. Can you people suggest > your favourite approach to IPC? If not, maybe we could look into > writing a very simple library (name-suggestion "sippy" :P) which > builds on top of UDS and implements a

Re: [dev] pledge(2) patches

On Mon, 06 Jun 2016, FRIGN wrote: > What it all brings up is the issue of IPC. Can you people suggest > your favourite approach to IPC? If not, maybe we could look into > writing a very simple library (name-suggestion "sippy" :P) which > builds on top of UDS and implements a very

Re: [dev] pledge(2) patches

On Mon, 6 Jun 2016 13:36:14 +0200 Martin Kühne wrote: Hey Martin, > Having done my own research, no it can't. Also, the way it is designed > is a rather silly approach to security which is much more revealing > about today's idiotic way of writing software by including tens

Re: [dev] pledge(2) patches

On Mon, 06 Jun 2016, Martin Kühne wrote: > Also, the way it is designed is a rather silly approach to security > which is much more revealing about today's idiotic way of writing > software by including tens of millions of SLOC of dependencies instead > of doing the one thing

Re: [dev] pledge(2) patches

On Mon, 06 Jun 2016, Martin Kühne wrote: > Can it somehow be made to keep its effect across the exec family of syscalls? > > cheers! > mar77i No. This is why pledging "stdio proc exec" is still quite dangerous. A well-designed program may try separating this functionality

Re: [dev] pledge(2) patches

On Mon, Jun 6, 2016 at 1:19 PM, Martin Kühne wrote: > Can it somehow be made to keep its effect across the exec family of syscalls? > Having done my own research, no it can't. Also, the way it is designed is a rather silly approach to security which is much more revealing

Re: [dev] pledge(2) patches

On 6 June 2016 at 12:19, Martin Kühne wrote: > Can it somehow be made to keep its effect across the exec family of syscalls? My understanding is that one can pledge not to call exec, but if one explicitly permits exec and it *is* called, the pledge no longer holds. cls

Re: [dev] pledge(2) patches

Can it somehow be made to keep its effect across the exec family of syscalls? cheers! mar77i

Re: [dev] pledge(2) patches

On Mon, 06 Jun 2016, Martin Kühne wrote: > I don't understand the purpose of pledge, since it's under the control > of the programmer, but so is what the program does just as well. In > what way is the programmer supposed to prevent himself from doing what > they were going to

Re: [dev] pledge(2) patches

On 6 June 2016 at 11:51, Martin Kühne wrote: > I don't understand the purpose of pledge, since it's under the control > of the programmer, but so is what the program does just as well. In > what way is the programmer supposed to prevent himself from doing what > they were

Re: [dev] pledge(2) patches

I don't understand the purpose of pledge, since it's under the control of the programmer, but so is what the program does just as well. In what way is the programmer supposed to prevent himself from doing what they were going to do anyway? cheers! mar77i

Re: [dev] pledge(2) patches

On Mon, 06 Jun 2016 10:02:05 +0200 Kamil Cholewiński wrote: Hey Kamil, > The "problem" with pledge, is you have to let the program initialise > completely, and only then drop the privileges. Otherwise it could've > been implemented as a flag on the executable file. You can

Re: [dev] pledge(2) patches

On Mon, 06 Jun 2016, Ben Woolley wrote: > But then, isn't that what config.h can do? Try it in config.h and see > how you feel. A lot of OS-specific features are enabled from > configuration in other software. The "problem" with pledge, is you have to let the program