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
