Re: Unix domain sockets and MAC confined processes as (object) capability system?

--===============8764966614157216415==
Content-Type: multipart/alternative; boundary=001a1142cf74334d29052c25b07b

--001a1142cf74334d29052c25b07b
Content-Type: text/plain; charset=UTF-8

On Thu, Feb 18, 2016 at 11:04 PM, rmeijer <rmeijer-qWit8jRvyhVmR6Xm/[email protected]> wrote:

> On Linux there are three interesting facilities regarding privilege
> separation:
>
> 1) Using MAC (SELinux/AppArmor/etc) a process can be functionally cut of
> from access
>    to most of the file-system.
> 2) Using UID based firewall rules, a process running under a particular
> UID can be functionally
>    cut of from initiating or directly accepting any network traffic.
>

I'd argue that it's easier, more elegant, and more robust to use Linux's
namespaces to achieve these two points. A mount namespace allows you to
define a new filesystem tree that can import specific directories from the
real one. A network namespace allows you to block network access. You can
also prevent the process from seeing other PIDs with a PID namespace
(important to prevent it from sending signals), etc.

(This is what sandstorm.io does.)


> 3) Using Unix domain sockets, open file, network connection handles and
> importantly other Unix
>    domain sockets can be handed over between processes.
>

Passing FDs over unix domain sockets comes pretty close to being
capability-based security. The big problem is that a lot of other file
descriptor types that you might introduce over a Unix domain socket are not
well-designed as object capabilities. For instance:
- A file descriptor for a directory will permit you to open ".." to get to
the parent directory an on up to the root. If you're in a mount namespace,
but the directory FD is *not* in the mount namespace, it will actually
provide full access to the filesystem outside the mount namespace.
- A socket FD can (I think) be re-bound to other addresses at will.
- If /proc is mounted, then you may be able to use it to re-open a file
descriptor with different access rights, with the permission check being
based on the underlying file's ACL and the caller's UID.
- Most file descriptor types cannot be emulated by another process. E.g. a
process cannot create a virtual file that behaves like a disk file
(allowing seeking, mmap, etc.). Userspace processes can really only create
pipes and sockets.

The Capsicum project is trying to fix a lot of these issues, but adoption
into Linux has been slow.

For Sandstorm, our solution is to avoid passing file descriptors across the
sandbox boundary, but instead have the app talk to the outside world using
Cap'n Proto, which is a true object capability protocol.


> If you combine these three techniques and keep the code-base of individual
> processes relatively small, you will have a privilege separated system
> that, if you consider a small-code-base process to be a coarse grained
> object, and if you consider the  Unix domain sockets, network connections
> and open file handles to be capabilities, has approximately the same
> semantic structure that a small program in an object capability language
> has.
>
> As such I've considered this type of privilege separation to effectively
> be not just a capability system but actually an object-capability system.
>
> Given some recent discussions however, I've found that either I'm wrong
> about this assertion, or that this view is simply confusing to people as
> multiple capability people seem to strongly be opposed to the idea that
> file handles on Unix could be capabilities at all, let alone object
> capabilities.
>
> My questions thus are:
>
> * Are there any reasons why a privilege separated program that uses a
> combination of above
>   techniques would not qualify as a capability system?
> * Are there reasons why open network connections, file handles and Unix
> domain sockets would
>   not qualify as (object) capabilities?
>
> Kind regards,
>
> Rob
> _______________________________________________
> cap-talk mailing list
> [email protected]
> http://www.eros-os.org/mailman/listinfo/cap-talk
>

--001a1142cf74334d29052c25b07b
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On T=
hu, Feb 18, 2016 at 11:04 PM, rmeijer <span dir=3D"ltr">&lt;<a href=3D"mail=
to:rmeijer-qWit8jRvyhVmR6Xm/[email protected]" target=3D"_blank">rmeijer-qWit8jRvyhVmR6Xm/[email protected]</a>&gt;</span> wr=
ote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border=
-left:1px #ccc solid;padding-left:1ex">On Linux there are three interesting=
 facilities regarding privilege separation:<br>
<br>
1) Using MAC (SELinux/AppArmor/etc) a process can be functionally cut of fr=
om access<br>
=C2=A0 =C2=A0to most of the file-system.<br>
2) Using UID based firewall rules, a process running under a particular UID=
 can be functionally<br>
=C2=A0 =C2=A0cut of from initiating or directly accepting any network traff=
ic.<br></blockquote><div><br></div><div>I&#39;d argue that it&#39;s easier,=
 more elegant, and more robust to use Linux&#39;s namespaces to achieve the=
se two points. A mount namespace allows you to define a new filesystem tree=
 that can import specific directories from the real one. A network namespac=
e allows you to block network access. You can also prevent the process from=
 seeing other PIDs with a PID namespace (important to prevent it from sendi=
ng signals), etc.</div><div><br></div><div>(This is what <a href=3D"http://=
sandstorm.io" target=3D"_blank">sandstorm.io</a> does.)</div><div>=C2=A0</d=
iv><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left=
:1px #ccc solid;padding-left:1ex">
3) Using Unix domain sockets, open file, network connection handles and imp=
ortantly other Unix<br>
=C2=A0 =C2=A0domain sockets can be handed over between processes.<br></bloc=
kquote><div><br></div><div>Passing FDs over unix domain sockets comes prett=
y close to being capability-based security. The big problem is that a lot o=
f other file descriptor types that you might introduce over a Unix domain s=
ocket are not well-designed as object capabilities. For instance:</div><div=
>- A file descriptor for a directory will permit you to open &quot;..&quot;=
 to get to the parent directory an on up to the root. If you&#39;re in a mo=
unt namespace, but the directory FD is *not* in the mount namespace, it wil=
l actually provide full access to the filesystem outside the mount namespac=
e.</div><div>- A socket FD can (I think) be re-bound to other addresses at =
will.</div><div>- If /proc is mounted, then you may be able to use it to re=
-open a file descriptor with different access rights, with the permission c=
heck being based on the underlying file&#39;s ACL and the caller&#39;s UID.=
</div><div>- Most file descriptor types cannot be emulated by another proce=
ss. E.g. a process cannot create a virtual file that behaves like a disk fi=
le (allowing seeking, mmap, etc.). Userspace processes can really only crea=
te pipes and sockets.</div><div><br></div><div>The Capsicum project is tryi=
ng to fix a lot of these issues, but adoption into Linux has been slow.</di=
v><div><br></div><div>For Sandstorm, our solution is to avoid passing file =
descriptors across the sandbox boundary, but instead have the app talk to t=
he outside world using Cap&#39;n Proto, which is a true object capability p=
rotocol.</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"m=
argin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">If you combin=
e these three techniques and keep the code-base of individual processes rel=
atively small, you will have a privilege separated system that, if you cons=
ider a small-code-base process to be a coarse grained object, and if you co=
nsider the=C2=A0 Unix domain sockets, network connections and open file han=
dles to be capabilities, has approximately the same semantic structure that=
 a small program in an object capability language has.<br>
<br>
As such I&#39;ve considered this type of privilege separation to effectivel=
y be not just a capability system but actually an object-capability system.=
<br>
<br>
Given some recent discussions however, I&#39;ve found that either I&#39;m w=
rong about this assertion, or that this view is simply confusing to people =
as multiple capability people seem to strongly be opposed to the idea that =
file handles on Unix could be capabilities at all, let alone object capabil=
ities.<br>
<br>
My questions thus are:<br>
<br>
* Are there any reasons why a privilege separated program that uses a combi=
nation of above<br>
=C2=A0 techniques would not qualify as a capability system?<br>
* Are there reasons why open network connections, file handles and Unix dom=
ain sockets would<br>
=C2=A0 not qualify as (object) capabilities?<br>
<br>
Kind regards,<br>
<br>
Rob<br>
_______________________________________________<br>
cap-talk mailing list<br>
<a href=3D"mailto:[email protected]" target=3D"_blank">cap-talk@mai=
l.eros-os.org</a><br>
<a href=3D"http://www.eros-os.org/mailman/listinfo/cap-talk" rel=3D"norefer=
rer" target=3D"_blank">http://www.eros-os.org/mailman/listinfo/cap-talk</a>=
<br>
</blockquote></div><br></div></div>

--001a1142cf74334d29052c25b07b--

--===============8764966614157216415==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
cap-talk mailing list
[email protected]
http://www.eros-os.org/mailman/listinfo/cap-talk

--===============8764966614157216415==--