Wow, Luke you are the man.
> Probably right, if they were pushing strong release dates, they'd go with
> freebsd or linux
>
> On Sat, Sep 3, 2016, 05:44 Theo de Raadt <dera...@openbsd.org> wrote:
>
> > Not a strong requirement.
> >
> > > If a program requires studio, wpath, rpath, dns, and inet. It spawns
> > > multiple threads. The socket binding thread is taken over, runs arbitrary
> > > code that overflows a buffer of the thread listening to a pipe with rpath
> > > and stdio permissions it reads the binary of an executable the company
> > > wants to remain private, but is on the paths list, which gives the
> > process
> > > unintentional read permissions and sends it to the attacker.
> > > Because we know everybody writes perfect code. With finer grained paths
> > > permissions, it is possible to gain even better control amidst really
> > well
> > > pledged and privilege separated programs(even if they are imperfectly
> > > bounded), it may be possible to have a slightly more complicated paths
> > > setup with less privilege separation, written by programmers that spend a
> > > bit less time with privilege separation, to meet deadlines and achieve
> > > comparable results.
> > >
> > > On Sat, Sep 3, 2016, 04:41 ludovic coues <cou...@gmail.com> wrote:
> > >
> > > > 2016-09-03 11:04 GMT+02:00 Luke Small <lukensm...@gmail.com>:
> > > > >
> > > > >
> > > > > Sorry I was in the middle of something, but pledge can be a broad
> > brush,
> > > > > unless you are dealing with one file, whether it is executed, read,
> > or
> > > > > written and giving per process file permissions sounds pretty neat,
> > and
> > > > it
> > > > > might just be a little simpler than making new users for each subset
> > of
> > > > > privileges, populating each chrooted home folder with a specific set
> > of
> > > > > permissions (as is what appears to me to have happened with pkg_add).
> > > > Since
> > > > > pledge's promises can make it where you can execute a file without
> > read
> > > > > permission, it seems ideal to continue that tradition with the paths
> > > > >
> > > > > On Sat, Sep 3, 2016, 03:07 Luke Small <lukensm...@gmail.com>
> > wrote:
> > > > >>
> > > > >> In pledge, presumably there will be an accessible paths list. Maybe
> > you
> > > > >> grant a process root access, and you need to read a file which is
> > only
> > > > >> granted by root access, and you need write access for another file,
> > so
> > > > the
> > > > >> pledge permissions reflect that. On the presumed current path, you
> > would
> > > > >> leave write access for the first file and maybe you don't need the
> > > > process
> > > > >> to have read permissions on an execl() program. You can prohibit
> > your
> > > > >> process from reading your software or binary, even if it may have
> > > > >> permissions to do so.
> > > > >>
> > > >
> > > > That's not a specific use case.
> > > > Either you should provide a patch or an exemple of a real program that
> > > > is limited by the current design of pledge.
> > > >
> > > > Currently, if you want a program that can only read a file, you pledge
> > > > rpath. If you want the ability to exec file, you pledge exec.
> > > >
> > > > If you want a program that can exec a set of file and write in
> > > > another, either you run your program as a user and group that can't
> > > > write the set of file you want to exec (W^X) or you write two program,
> > > > one pledging for write the other for read.
> > > >
> > > > There following paper have an exemple of how the second design can be
> > done.
> > > > http://quigon.bsws.de/papers/2014/asiabsdcon/mgp00010.html
> > > >
> > > >
> > > > --
> > > >
> > > > Cordialement, Coues Ludovic
> > > > +336 148 743 42
> > >
> >
> >
>
> --94eb2c07d10429a200053b98ce09
> Content-Type: text/html; charset=UTF-8
> Content-Transfer-Encoding: quoted-printable
>
> <p dir=3D"ltr">Probably right, if they were pushing strong release dates, t=
> hey'd go with freebsd or linux</p>
> <br><div class=3D"gmail_quote"><div dir=3D"ltr">On Sat, Sep 3, 2016, 05:44 =
> Theo de Raadt <<a href=3D"mailto:dera...@openbsd.org";>dera...@openbsd.or=
> g</a>> wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin=
> :0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Not a strong requi=
> rement.<br>
> <br>
> > If a program requires studio, wpath, rpath, dns, and inet. It spawns<b=
> r>
> > multiple threads. The socket binding thread is taken over, runs arbitr=
> ary<br>
> > code that overflows a buffer of the thread listening to a pipe with rp=
> ath<br>
> > and stdio permissions it reads the binary of an executable the company=
> <br>
> > wants to remain private, but is on the paths list, which gives the pro=
> cess<br>
> > unintentional read permissions and sends it to the attacker.<br>
> > Because we know everybody writes perfect code. With finer grained path=
> s<br>
> > permissions, it is possible to gain even better control amidst really =
> well<br>
> > pledged and privilege separated programs(even if they are imperfectly<=
> br>
> > bounded), it may be possible to have a slightly more complicated paths=
> <br>
> > setup with less privilege separation, written by programmers that spen=
> d a<br>
> > bit less time with privilege separation, to meet deadlines and achieve=
> <br>
> > comparable results.<br>
> ><br>
> > On Sat, Sep 3, 2016, 04:41 ludovic coues <<a href=3D"mailto:couesl@=
> gmail.com" target=3D"_blank">cou...@gmail.com</a>> wrote:<br>
> ><br>
> > > 2016-09-03 11:04 GMT+02:00 Luke Small <<a href=3D"mailto:luken=
> sm...@gmail.com" target=3D"_blank">lukensm...@gmail.com</a>>:<br>
> > > ><br>
> > > ><br>
> > > > Sorry=C2=A0 I was in the middle of something, but pledge can=
> be a broad brush,<br>
> > > > unless you are dealing with one file, whether it is executed=
> , read, or<br>
> > > > written and giving per process file permissions sounds prett=
> y neat, and<br>
> > > it<br>
> > > > might just be a little simpler than making new users for eac=
> h subset of<br>
> > > > privileges, populating each chrooted home folder with a spec=
> ific set of<br>
> > > > permissions (as is what appears to me to have happened with =
> pkg_add).<br>
> > > Since<br>
> > > > pledge's promises can make it where you can execute a fi=
> le without read<br>
> > > > permission, it seems ideal to continue that tradition with t=
> he paths<br>
> > > ><br>
> > > >=C2=A0 =C2=A0On Sat, Sep 3, 2016, 03:07 Luke Small <<a hre=
> f=3D"mailto:lukensm...@gmail.com"; target=3D"_blank">lukensm...@gmail.com</a=
> >> wrote:<br>
> > > >><br>
> > > >> In pledge, presumably there will be an accessible paths =
> list. Maybe you<br>
> > > >> grant a process root access, and you need to read a file=
> which is only<br>
> > > >> granted by root access, and you need write access for an=
> other file, so<br>
> > > the<br>
> > > >> pledge permissions reflect that. On the presumed current=
> path, you would<br>
> > > >> leave write access for the first file and maybe you don&=
> #39;t need the<br>
> > > process<br>
> > > >> to have read permissions on an execl() program. You can =
> prohibit your<br>
> > > >> process from reading your software or binary, even if it=
> may have<br>
> > > >> permissions to do so.<br>
> > > >><br>
> > ><br>
> > > That's not a specific use case.<br>
> > > Either you should provide a patch or an exemple of a real program=
> that<br>
> > > is limited by the current design of pledge.<br>
> > ><br>
> > > Currently, if you want a program that can only read a file, you p=
> ledge<br>
> > > rpath. If you want the ability to exec file, you pledge exec.<br>
> > ><br>
> > > If you want a program that can exec a set of file and write in<br=
> >
> > > another, either you run your program as a user and group that can=
> 't<br>
> > > write the set of file you want to exec (W^X) or you write two pro=
> gram,<br>
> > > one pledging for write the other for read.<br>
> > ><br>
> > > There following paper have an exemple of how the second design ca=
> n be done.<br>
> > > <a href=3D"http://quigon.bsws.de/papers/2014/asiabsdcon/mgp00010.=
> html" rel=3D"noreferrer" target=3D"_blank">http://quigon.bsws.de/papers/201=
> 4/asiabsdcon/mgp00010.html</a><br>
> > ><br>
> > ><br>
> > > --<br>
> > ><br>
> > > Cordialement, Coues Ludovic<br>
> > > +336 148 743 42<br>
> ><br>
> <br>
> </blockquote></div>
>
> --94eb2c07d10429a200053b98ce09--
