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

Re: [dev] pledge(2) patches

On Sun, 5 Jun 2016 13:11:15 -0700 Ben Woolley wrote: Hey Ben, > Regarding #2, the usage stats of openbsd should be joined with the > usage stats of st. I don't know the answer, but I am guessing not > insignificant, especially since an openbsd user was driven to do it >

Re: [dev] pledge(2) patches

> On Jun 5, 2016, at 11:59 AM, FRIGN wrote: > > On Fri, 03 Jun 2016 19:46:18 +0200 > Christoph Lohmann <2...@r-36.net> wrote: > > Hey Christoph, > >> Adding sloc will never get you security. > > This is right in many cases, but for pledge(1) it makes sense, > however, there

Re: [dev] pledge(2) patches

On Fri, 03 Jun 2016 19:46:18 +0200 Christoph Lohmann <2...@r-36.net> wrote: Hey Christoph, > Adding sloc will never get you security. This is right in many cases, but for pledge(1) it makes sense, however, there are 2 reasons why I would oppose a mainline- include as well: 1) starting with

Re: [dev] pledge(2) patches

Greetings. On Fri, 03 Jun 2016 19:46:18 +0200 Kamil Cholewiński wrote: > On Fri, 03 Jun 2016, Christoph Lohmann <2...@r-36.net> wrote: > > For st this will never be included in mainline. Please add it do the wi‐ > > ki, if you think it’s relevant for others. > > I will try

Re: [dev] pledge(2) patches

On Fri, 03 Jun 2016, Christoph Lohmann <2...@r-36.net> wrote: > For st this will never be included in mainline. Please add it do the wi‐ > ki, if you think it’s relevant for others. I will try having it accepted in ports first. Security shouldn't be opt-in. <3,K.

Re: [dev] pledge(2) patches

Greetings. On Fri, 03 Jun 2016 14:51:10 +0200 Kamil Cholewiński wrote: > Included are pledge(2) diffs for dwm, dmenu, st and slock. I've been > testing these for a week now (both stress-tests and normal usage), and I > have no ill effects to report. For st this will never

Re: [dev] pledge(2) patches

Hi all, new versions of all four patches attached. Changes: - Added dummy pledge definition on other platforms - Added xpledge, refactored - Added rpath to final pledge in dwm; turns out xfont sometimes wants new fonts at runtime. Cheers! K. diff --git a/dmenu.c b/dmenu.c index

Re: [dev] pledge(2) patches

On Wed, May 18, 2016 at 02:46:16PM -0700, Evan Gates wrote: > > #ifndef __OpenBSD__ > > int pledge(const char *promises, const char *paths[]) { return 0; } > > #endif > > Why the full function instead of > > #define pledge(x,y) 0 > > (perhaps to enforce correct types?) When using such trick

Re: [dev] pledge(2) patches

> #ifndef __OpenBSD__ > int pledge(const char *promises, const char *paths[]) { return 0; } > #endif Why the full function instead of #define pledge(x,y) 0 (perhaps to enforce correct types?) -emg

Re: [dev] pledge(2) patches

On Wed, 18 May 2016 18:50:15 +0200 Kamil Cholewiński wrote: Hey Kamil, > Included are pledge(2) diffs for dwm, dmenu, st and slock. I've been > testing these for a week now (both stress-tests and normal usage), and I > have no ill effects to report. I would never welcome

Re: [dev] pledge(2) patches

On Wed, May 18, 2016 at 06:50:15PM +0200, Kamil Cholewiński wrote: > Hi folks, > > This is purely OpenBSD-specific; had a brief look at SecComp and > promptly ran away. > > Included are pledge(2) diffs for dwm, dmenu, st and slock. I've been > testing these for a week now (both stress-tests and

Re: [dev] pledge(2) patches

On Wed, 18 May 2016, Marc André Tanner wrote: > Independent of whether the functionality is desired, you probably want > to implement it along the lines of: > > #ifndef __OpenBSD__ > int pledge(const char *promises, const char *paths[]) { return 0; } > #endif > > This way

Re: [dev] pledge(2) patches

On Wed, May 18, 2016 at 06:50:15PM +0200, Kamil Cholewiński wrote: > +#if defined(__OpenBSD__) > + if (pledge("stdio rpath dns unix prot_exec proc exec", NULL) < 0) { > + die("pledge\n"); > + } > +#endif Independent of whether the functionality is desired, you probably want to