On 2015-11-17 17:01, Seth Forshee wrote:
On Tue, Nov 17, 2015 at 09:05:42PM +0000, Al Viro wrote:On Tue, Nov 17, 2015 at 03:39:16PM -0500, Austin S Hemmelgarn wrote:This is absolutely insane, no matter how much LSM snake oil you slatter on the whole thing. All of a sudden you are exposing a huge attack surface in the place where it would hurt most and as the consolation we are offered basically "Ted is willing to fix holes when they are found".None of the LSM changes are intended to protect against attacks from these sorts of attacks at all, so that's irrelevant. As I said before, I'm also working to find holes up front. That plus a commitment from the maintainer seems like a good start at least. What bar would you set for a given filesystem to be considered "safe enough"?For the context of static image attacks, anything that's foun _needs_ to be fixed regardless, and unless you can find some way to actually prevent attacks on mounted filesystems that doesn't involve a complete re-write of the filesystem drivers, then there's not much we can do about it. Yes, unprivileged mounts expose an attack surface, but so does userspace access to the network stack, and so do a lot of other features that are considered essential in a modern general purpose operating system."X is exposes an attack surface. Y exposes a diferent attack surface. Y is considered important. Therefore X is important enough to implement it" Right...That isn't the argument he made. I would summarize the argument as, "Saying that X exposes an attack surface isn't by itself enough to reject X, otherwise we wouldn't expose anything (such as example Y)."
It's good to see someone understood my meaning...
While I can't speak for Al's opinion on this, I would like to point out my earlier comment: > It's unfeasible from a practical standpoint to expect filesystems to > assume that stuff they write might change under them due to malicious > intent of a third party. We can't protect against everything, not without making the system completely unusable for general purpose computing. There is always some degree of trust involved in usage of a computer, the OS has to trust that the hardware works correctly, the administrator has to trust the OS to behave correctly, and the users have to trust the administrator. The administrator also needs to have at least some trust in the users, otherwise he shouldn't be allowing them to use the system.You believe that the attack surface is too large, and that's understandable. Is it your opinion that this is a fundamental problem for an in-kernel filesystem driver, i.e. that we can never be confident enough in an in-kernel filesystem parser to allow untrusted data? If not, what would it take to establish a level of confidence that you would be comfortable with?
Perhaps we should have an option that can only be enabled on creation of the userns that would allow it to use regular kernel mounts, and without that option we default to only allowing FUSE and a couple of virtual filesystems (like /proc and devtmpfs).
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature
