On Tue, Aug 23, 2016 at 5:33 PM John <[1]jnn@synfin.org> wrote:

     On August 23, 2016 5:56:39 PM EDT, Sean Lynch
     <[2]seanl@literati.org> wrote:
     ...
     >"Docker for everything" is not a totally off the wall idea. Not
     >specifically docker but namespaces & cgroups for making software
     that's
     >used to Unix-like discretionary access controls and make it act
     more
     >like
     >object-capability software. You'd need a UI or shell or something
     for
     >expressing what capabilities to pass along, for example something
     that
     >interprets annotated filenames, converts them to filenames in the
     >process's
     >own namespace, and handles mounting the files into the process's
     >namespace.
     >Of course, then you're probably just reinventing SELinux or
     something,
     >though I do think there's potential there to make the user
     interface a
     >little less obtuse than SELinux policies.
     I don't need /bin/ls and /bin/cp and /bin/[insert simple base util
     here] wrapped in a container and never found SELinux worth the
     hassle, but I suppose some people might want that level of
     headache... ;).

   Sure, the base utilities are *probably* secure, but only because
   they're mature at this point. But /bin/ls and /bin/cp have access to
   everything you do, and they an allocate arbitrary amounts of RAM, open
   network sockets, delete all your files, DoS the whole machine. Not too
   hard to avoid some of that with ulimit et al, but where do you draw the
   line at what's a "base utility"? tar? rar? mawk? And what happens the
   next time someone puts a "bug fix" into ls that causes a security
   regression?
   /bin/ls only needs access to your current directory or the directories
   you type on the command line, and to the inodes of any of the files
   therein. And then only read access. I suspect that wouldn't be too hard
   to add as annotations to the arguments themselves, similar to how we
   have wildcards that are interpreted by the shell now. Automatic named
   pipes are probably a better analogy.
   Now I feel like I need to go code up a prototype...

References

   1. mailto:jnn@synfin.org
   2. mailto:seanl@literati.org