<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<br>
<br>
<div class="moz-cite-prefix">On 11/18/2015 10:38 AM, Austin S
Hemmelgarn wrote:<br>
</div>
<blockquote cite="mid:564C9B92.5080107@gmail.com" type="cite">On
2015-11-18 09:30, Seth Forshee wrote:
<br>
<blockquote type="cite">On Wed, Nov 18, 2015 at 07:46:53AM -0500,
Austin S Hemmelgarn wrote:
<br>
<blockquote type="cite">On 2015-11-17 17:01, Seth Forshee wrote:
<br>
<blockquote type="cite">On Tue, Nov 17, 2015 at 09:05:42PM
+0000, Al Viro wrote:
<br>
<blockquote type="cite">On Tue, Nov 17, 2015 at 03:39:16PM
-0500, Austin S Hemmelgarn wrote:
<br>
<br>
<blockquote type="cite">
<blockquote type="cite">This is absolutely insane, no
matter how much LSM snake oil you slatter on
<br>
the whole thing. All of a sudden you are exposing a
huge attack surface
<br>
in the place where it would hurt most and as the
consolation we are offered
<br>
basically "Ted is willing to fix holes when they are
found".
<br>
</blockquote>
</blockquote>
</blockquote>
<br>
None of the LSM changes are intended to protect against
attacks from
<br>
these sorts of attacks at all, so that's irrelevant.
<br>
<br>
As I said before, I'm also working to find holes up front.
That plus a
<br>
commitment from the maintainer seems like a good start at
least. What
<br>
bar would you set for a given filesystem to be considered
"safe enough"?
<br>
<br>
<blockquote type="cite">
<blockquote type="cite">For the context of static image
attacks, anything that's foun
<br>
_needs_ to be fixed regardless, and unless you can find
some way to
<br>
actually prevent attacks on mounted filesystems that
doesn't involve
<br>
a complete re-write of the filesystem drivers, then
there's not much
<br>
we can do about it. Yes, unprivileged mounts expose an
attack
<br>
surface, but so does userspace access to the network
stack, and so
<br>
do a lot of other features that are considered essential
in a modern
<br>
general purpose operating system.
<br>
</blockquote>
<br>
"X is exposes an attack surface. Y exposes a diferent
attack surface.
<br>
Y is considered important. Therefore X is important
enough to implement it"
<br>
<br>
Right...
<br>
</blockquote>
<br>
That isn't the argument he made. I would summarize the
argument as,
<br>
"Saying that X exposes an attack surface isn't by itself
enough to
<br>
reject X, otherwise we wouldn't expose anything (such as
example Y)."
<br>
</blockquote>
It's good to see someone understood my meaning...
<br>
<blockquote type="cite">
<br>
You believe that the attack surface is too large, and that's
<br>
understandable. Is it your opinion that this is a
fundamental problem
<br>
for an in-kernel filesystem driver, i.e. that we can never
be confident
<br>
enough in an in-kernel filesystem parser to allow untrusted
data? If
<br>
not, what would it take to establish a level of confidence
that you
<br>
would be comfortable with?
<br>
</blockquote>
While I can't speak for Al's opinion on this, I would like to
point
<br>
out my earlier comment:
<br>
<blockquote type="cite">It's unfeasible from a practical
standpoint to expect filesystems
<br>
</blockquote>
to > assume that stuff they write might change under them
due to
<br>
malicious > intent of a third party.
<br>
</blockquote>
<br>
So maybe the first requirement is that the user cannot modify
the
<br>
backing store directly while the device is mounted.
<br>
<br>
<blockquote type="cite">We can't protect against everything, not
without making the system
<br>
completely unusable for general purpose computing. There is
always
<br>
some degree of trust involved in usage of a computer, the OS
has to
<br>
trust that the hardware works correctly, the administrator has
to
<br>
trust the OS to behave correctly, and the users have to trust
the
<br>
administrator. The administrator also needs to have at least
some
<br>
trust in the users, otherwise he shouldn't be allowing them to
use
<br>
the system.
<br>
<br>
Perhaps we should have an option that can only be enabled on
<br>
creation of the userns that would allow it to use regular
kernel
<br>
mounts, and without that option we default to only allowing
FUSE and
<br>
a couple of virtual filesystems (like /proc and devtmpfs).
<br>
</blockquote>
<br>
I've considered the idea of something more global like a sysctl,
or a
<br>
per-filesystem knob in sysfs. I guess a per-container knob is
another
<br>
option, I'm not sure what interface we use to expose it though.
<br>
<br>
</blockquote>
The most useful way I can see of implementing this would be to
have an option on container creation that controls whether kernel
mounts are allowed or not (possibly have it allow any of {no
mounts, only FUSE mounts, all mounts}), and then have a sysctl to
set the default for containers created without this option (and
possibly one to force all containers to ignore the option, and
just use the default).
<br>
<br>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
Selinux mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Selinux@tycho.nsa.gov">Selinux@tycho.nsa.gov</a>
To unsubscribe, send email to <a class="moz-txt-link-abbreviated" href="mailto:Selinux-leave@tycho.nsa.gov">Selinux-leave@tycho.nsa.gov</a>.
To get help, send an email containing "help" to <a class="moz-txt-link-abbreviated" href="mailto:Selinux-request@tycho.nsa.gov">Selinux-request@tycho.nsa.gov</a>.</pre>
</blockquote>
From a safely/security point of view. I think you should focus on
the clear linux containers model for allowing containers on hosting
providers. If we need "guaranteed" separation you really need to
take advantage of kvm and each container using its own kernel. In
standard containers if a process can talk directly to the host
kernel, any kernel bug could potentially allow a break out.<br>
</body>
</html>