ebiederm@xxxxxxxxxxxx (Eric W. Biederman) writes: > 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? Thinking about it a little more. There is a possibility that sometime in the future that someone will deliberately add a suid executable as a file in proc or sysfs and have a good reason for doing so. Some sysadmin or sandbox builder with special requirements may then disable suid and exec on proc because in their sandbox (not linux in general) having access to that executable is a bad thing. At which we have an exploitable security issue if nosuid and noexec are not enforced. Or in other words I am not smarter than the bad guys. This is a security issue. I can not ignore nosuid and noexec indefinitely. I have to make those cases fail at some point. At that point current unfixed versions of lxc and libvirt-lxc will break. A warning is the nicest I can imagine being. Eric -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
