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
