Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx> writes: > On Wed, Jun 03, 2015 at 04:13:21PM -0500, Eric W. Biederman wrote: >> Andy Lutomirski <luto@xxxxxxxxxxxxxx> writes: >> >> > One option would be to break the nosuid, nodev, and noexec parts into >> > their own patch and then avoid tagging that patch for -stable if at >> > all possible. It would be nice to avoid another -stable ABI break if >> > at all possible. >> >> So I don't think we actually have anything that could be called an ABI >> break in the whole mess, but it is definitely a behavioral change that >> is a regression for lxc and libvirt-lxc that prevents them from starting. >> >> nodev does not actually matter because of the implicit silliness that >> is being added right now. >> >> We do want those programs fixed and after those programs are fixed we >> can safely begin failing mount when those attributes are being cleared >> in a fresh mount. >> >> So it looks to me like the best thing to do is to print a warning >> whenever lxc or libvirt-lxc gets it wrong, which should ensure the >> authors are sufficiently pestered that in a kernel release or 3 we can >> begin enforcing those attributes. Especially as the discussion on the >> fix for those applications has already begun. > > "pestering" never works, look at some of the SCSI drivers for examples > of how a distro will just patch out the "warning this driver is using an > old api and needs to be fixed" messages. > You can't break stuff like this, people will get upset :( A) To the best of my knowledge there are two programs on the face of the planet where this matters. (lxc and libvirt-lxc) B) The code in those two programs is buggy. That is the code in those two programs does not do what the authors intended. That is fixing those programs is something that should be done regardless of what I do in the kernel. I have already reached out to the developers of those programs. The pestering in the kernel is a form of reminder, not the primary source of communication. C) These bugs really are security holes. Currently they do not appear exploitable (thank goodness) but they are security holes. Since they are not currently exploitable it does make sense to give people a little time to get their act together. The bugs are larger then the case that is being hit here, this is just where they are noticed. D) Letting people know that there is a problem as part of a larger effort has actually worked for me. Distro's have stopped enabling the sysctl system call. E) Given that I have not audited sysfs and proc closely in recent years I may actually be wrong. Those bugs may actually be exploitable. All it takes is chmod to be supported on one file that can be made executable. That bug has existed in the past and I don't doubt someone will overlook something and we will see the bug again in the future. So it is my best judgment that I disable the code that stops containers from starting and just making it a warning (for now). Then in a release or so I start failing these operations instead of warning. This is the most fair and reasonable I can see to be. The only other choice I can see is to say I don't care it is a security issue I am breaking your sloopy insecure code. Am I being too nice with these security bugs? Eric _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linuxfoundation.org/mailman/listinfo/containers
