VSOCK & getpeercon()

[Paul Moore]

On Fri, Jan 22, 2021 at 12:13 PM Casey Schaufler <casey at schaufler-ca.com> wrote:
> On 1/22/2021 8:27 AM, Paul Moore wrote:
> > On Sat, Jan 16, 2021 at 7:48 AM Marc-André Lureau
> > <marcandre.lureau at gmail.com> wrote:
> >> Hi,
> >>
> >> getpeercon() isn't implemented for VSOCK. Note, I am not very familiar
> >> with SELinux, but I was porting some applications that uses AF_UNIX to
> >> AF_VSOCK and reached that point.
> >>
> >> I found some previous discussions about VSOCK & LSM from 2013, but the
> >> reasons it was abandoned don't seem so clear or valid to me:
> >> https://lore.kernel.org/selinux/1803195.0cVPJuGAEx@sifl/
> > Hi, my apologies for the slow reply.
> >
> > The SELinux/LSM VSOCK support wasn't abandoned due to any significant
> > roadblocks, it was simply a matter of time - I seemed to be the only
> > one who was interested in working on it, and I couldn't find enough
> > time to work on it ;)
> >
> > If you are interested in spending some time on adding proper
> > LSM/SELinux VSOCK support my gut feeling is that it would still be a
> > good thing.  However, I would suggest spending some time investigating
> > the current state of things, while you may get lucky, I believe it is
> > safer to assume that anything from 2013 is horribly out of date.
>
> That's a pretty safe statement. You really have four options at
> this point:
>
> - netfilter to set the secmark
> - CIPSO/CALIPSO if the protocol supports or can support options
> - examining the peer process as is done with AF_UNIX
> - eBPF *I think* but you never really know with something that new

I don't believe CIPSO, CALIPSO, labeled IPsec and other IP-based
labeling protocols aren't really options here since VSOCK doesn't rely
on IP.  I vaguely recall thinking it was much more analogous to
UNIX/LOCAL sockets, but it has been ~seven years since I thought about
this last.

The use of secmark could be interesting assuming there are useful
labeling points for VSOCK and netfilter (secmark'ing a packet doesn't
rely on IP so it should be okay from that perspective).

Of course eBPF support would be interesting, but that is like saying
SELinux, Smack, and AppArmor support would be interesting.  I think
the important part is making sure the important objects include the
necessary opaque security blobs (we are probably okay there already),
and making sure we have the LSM hooks in the right places in the code
(also, we *may* be okay there).  Once those things are done, it's a
matter of adding the necessary support to each LSM.

> There may be something else out there that hasn't gobsmacked me
> in the stacking work, so that I wouldn't know about it.
>
> BTW: Please include the (CCed) Linux Security Module list
> <linux-security-module at vger.kernel.org> in discussions like this.

-- 
paul moore
www.paul-moore.com