Re: user namespaces

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]




Am 02.02.2017 um 17:45 schrieb Daniel Micay via arch-general:
> SubgraphOS doesn't use user namespaces.

It also is not a lightweight solution that compares to the tools in
question for that matter. But I get your point.


>> I was under the impression that all
>> namespaces were enabled by default. That changes things to some
>> extend.
> 
> All but user namespaces. The other namespaces do not present any real
> risk by default, since only privileged users have access to them. User
> namespaces greatly reduce security unless they are disabled at runtime.
> A system designed around user namespaces can make sure that EVERYTHING
> runs in a user namespace with user namespaces disabled within them, but
> on a general purpose system it's a big problem, and that's also the case
> for a general purpose system with a few sandboxes. Not to mention that
> user namespaces accomplish essentially nothing for security and the only
> reason you or anyone else wants them is fact that they open up the
> unpriv use can of worms, but it's much less secure than alternative
> approaches to that. It is NOT necessary or even desirable for that. It
> is only wanted for the political reasons I've already gone into.
> 

I get it. User namespaces privide a wide attack surface to the kernel
and decrease security and as you pointed out, the only reason to use it
is to get access to priviliges features like other namespaces as an
unprivileged user.

The reason me and I dare to say likely many others cling to this feature
is the impressive isolation namespaces provide for sandboxing and I do
not see comparable ways to do this.

But I agree that we need secure sandboxing solutions.

Using bubblewrap with suid on a system without unprivileged user
namespaces would be the closest thing I know right now.


>>
>> Not that there are not enoght weak points in sandboxing as long as
>> things like X11 are available.
> 
> The point is that they are truly not usable for sandboxing desktop apps
> and that's the only niche that's not well covered already.
> 

Would you care to elaborate this point?
As said before I think things like flatpak/bubblewrap can be used if
carefully designed.
If your point is that it does not allow normal users to safely use it
without detailed knowledge of sandboxing weakpoints i would agree. But
other then that it is kind of lost on me what draws you to this
conclusion. Or rather what would qualify as secure sandbox in your opinion.



> 
> Separately from that, generic sandboxing is a lot weaker than integrated
> sandboxing which you imply by stating *strong* seccomp filters. In that
> case namespaces are not really required.

In regards to sandboxing desktop applications, seccomp would not be
enough. Even wayland cannot be secured without further isolation:
https://github.com/MaartenBaert/wayland-keylogger

And I have yet to find a successful attempt to filter socket
communication for blocking dbus.

Still hoping for bus1 to evolve soon.


> I doubt it. Anyway, linux-grsec is in the official repositories. No one
> really wants / needs user namespaces though. They want *unprivileged*
> access to namespaces.

Then I will drop this topic as it has become clear to me that you know
what you are talking about here.

Attachment: signature.asc
Description: OpenPGP digital signature


[Index of Archives]     [Linux Wireless]     [Linux Kernel]     [ATH6KL]     [Linux Bluetooth]     [Linux Netdev]     [Kernel Newbies]     [Share Photos]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Samba]     [Device Mapper]
  Powered by Linux