Ted Unangst wrote:
> Theo de Raadt wrote:
> > > unveil isn't really buying much if you pledge "rpath" immediately after,
> > > so if you want just add another pledge here instead, that is fine.
> >
> > "rpath" is obviously cheaper than unveil of even 1 file.
>
> here is a diff that simply adds
On Fri, Jan 04, 2019 at 11:52:05AM -0500, Ted Unangst wrote:
> Theo de Raadt wrote:
> > > unveil isn't really buying much if you pledge "rpath" immediately after,
> > > so if you want just add another pledge here instead, that is fine.
> >
> > "rpath" is obviously cheaper than unveil of even 1
Theo de Raadt wrote:
> > unveil isn't really buying much if you pledge "rpath" immediately after,
> > so if you want just add another pledge here instead, that is fine.
>
> "rpath" is obviously cheaper than unveil of even 1 file.
here is a diff that simply adds another pledge.
the attack
> Just saying "you should not do that" will not prevent any user to do it
> anyway.
That is not what I was saying.
Most of us strive to write utilities in the most efficient way. We don't
use system features in programs that don't require it. We write a sparing
but sufficient userland.
That's
> But, is the situation with unveil(2) worst that before ? It seems to me
> a user could already doing vnode comsuption with just opening as many
> file descriptors it can (and fork and repeat when RLIMIT_NOFILES is
> reached for the process).
No, it is a little different.
An unveil is a tighter
Hi,
First, for the specific case of file(1), I agree that calling "rpath" is what
to do. No point to use unveil("/", "r").
On Thu, Jan 03, 2019 at 06:34:06PM -0700, Theo de Raadt wrote:
>
> You are abusing kernel resources.
>
if a userland program could be be crafted to abuse kernel
> unveil isn't really buying much if you pledge "rpath" immediately after,
> so if you want just add another pledge here instead, that is fine.
"rpath" is obviously cheaper than unveil of even 1 file.
On Thu, Jan 03, 2019 at 08:26:00PM -0500, Ted Unangst wrote:
> Ted Unangst wrote:
> > Bryan Steele wrote:
> > > It is not possible to unveil(2) all arguments passed to file(1), as this
> > > would require walking *argv. Instead, we can unveil("/", "r") to permit
> > > readonly access to the entire
Ted Unangst wrote:
> Ted Unangst wrote:
> > Bryan Steele wrote:
> > > It is not possible to unveil(2) all arguments passed to file(1), as this
> > > would require walking *argv. Instead, we can unveil("/", "r") to permit
> > > readonly access to the entire filesystem, while restricting all
Ted Unangst wrote:
> Bryan Steele wrote:
> > It is not possible to unveil(2) all arguments passed to file(1), as this
> > would require walking *argv. Instead, we can unveil("/", "r") to permit
> > readonly access to the entire filesystem, while restricting all execute
> > write, and create
Ted Unangst wrote:
> Bryan Steele wrote:
> > It is not possible to unveil(2) all arguments passed to file(1), as this
> > would require walking *argv. Instead, we can unveil("/", "r") to permit
> > readonly access to the entire filesystem, while restricting all execute
> > write, and create
Bryan Steele wrote:
> It is not possible to unveil(2) all arguments passed to file(1), as this
> would require walking *argv. Instead, we can unveil("/", "r") to permit
> readonly access to the entire filesystem, while restricting all execute
> write, and create operations.
Why not? Because of
It is not possible to unveil(2) all arguments passed to file(1), as this
would require walking *argv. Instead, we can unveil("/", "r") to permit
readonly access to the entire filesystem, while restricting all execute
write, and create operations.
This only provides some additional early
13 matches
Mail list logo
