<html><head></head><body>That's where MAC system comes handy.<br>
<br>
-- <br>
Sent from my Android phone with K-9 Mail. Please excuse my brevity.<br><br><div class="gmail_quote">"Michael H. Warfield" <mhw@WittsEnd.com> wrote:<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<pre style="white-space: pre-wrap; word-wrap:break-word; font-family: sans-serif">On Sun, 2011-07-31 at 17:59 +0200, Robert Kawecki wrote: <br />> Dnia 2011-07-30, sob o godzinie 21:10 -0400, Matthew Franz pisze:<br />> > Had seen some previous discussions before, but are there any ways to<br />> > mitigate this design vulnerability?<br />> > <br />> > <a href="http://blog.bofh.it/debian/id_413">http://blog.bofh.it/debian/id_413</a><br />> > <br />> > Are there any workarounds?<br />> > <br />> > Thanks,<br />> > <br />> > - mdf<br />> > <br />> <br />> The blog post explicitly mounts /sys... Why would you want your<br />> container to even have the capability to mount anything?<br /><br />Let's see...  Where shall we start.  If you're containerizing a<br />"machine" or full system there's a laundry list of reasons you would<br />want to.  Maybe you want to mount an image, like a CD image or maybe an<br
/>encrypted file system?  Then, there's a variety of fuse file systems you<br />might want access to for a variety of reasons.<br /><br />Maybe you want to run a service, like bind's named in a bind mounted<br />chrooted environment (default for running name servers on Fedora for<br />some time now:<br /><br />/var/named on /var/named/chroot/var/named type none (rw,bind)<br />/var/named/etc/named.conf on /var/named/chroot/etc/named.conf type none (rw,bind)<br />/etc/named.rfc1912.zones on /var/named/chroot/etc/named.rfc1912.zones type none (rw,bind)<br />/etc/rndc.conf on /var/named/chroot/etc/rndc.conf type none (rw,bind)<br />/etc/rndc.key on /var/named/chroot/etc/rndc.key type none (rw,bind)<br />/usr/lib/bind on /var/named/chroot/usr/lib/bind type none (rw,bind)<br />/etc/named.iscdlv.key on /var/named/chroot/etc/named.iscdlv.key type none (rw,bind)<br />/etc/named.root.key on /var/named/chroot/etc/named.root.key type none (rw,bind)<br /><br />That gets done by "service named
start".<br /><br />> If possible, drop CAP_SYS_ADMIN.<br /><br />That's been proposed as a workaround for some of the remount problems we<br />have to where a partition is suppose to be mounted ro but the container<br />can remount it rw.  I've actually tried that trick.  Yeah, that was an<br />epic failure.<br /><br />Generally not possible in a generalized system container.  Way too many<br />things are impacted by CAP_SYS_ADMIN.  Disabling that, you can't even<br />set your own hostname in the container.  You can't set crypto keys<br />either.  That's a sledge hammer approach that won't work in many if not<br />most system containers.  A simply application container?  It might work<br />in, depending on the application.<br /><br />Check out "man capabilities" and scroll down to CAP_SYS_ADMIN and look<br />at that laundry list under it (and I'm not totally sure that list is<br />comprehensive in the man page either) and honestly say there are not<br />reasons for a container
wanting to do at least one or two of them (even<br />given that every container I have sets its own hostname).<br /><br />Gotta be a better answer than that.<br /><br />Regards,<br />Mike<br />-- <br />Michael H. Warfield (AI4NB) | (770) 985-6132 |  mhw@WittsEnd.com<br />   /\/\|=mhw=|\/\/          | (678) 463-0932 |  <a href="http://www.wittsend.com/mhw">http://www.wittsend.com/mhw</a>/<br />   NIC whois: MHW9          | An optimist believes we live in the best of all<br /> PGP Key: 0x674627FF        | possible worlds.  A pessimist is sure of it!<br /><hr /><br />Got Input?   Slashdot Needs You.<br />Take our quick survey online.  Come on, we don't ask for help often.<br />Plus, you'll get a chance to win $100 to spend on ThinkGeek.<br /><a href="http://p.sf.net/sfu/slashdot-survey">http://p.sf.net/sfu/slashdot-survey</a><hr /><br />Lxc-users mailing list<br />Lxc-users@lists.sourceforge.net<br /><a
href="https://lists.sourceforge.net/lists/listinfo/lxc-users">https://lists.sourceforge.net/lists/listinfo/lxc-users</a><br /></pre></blockquote></div></body></html>