VSOCK & getpeercon()

VSOCK & getpeercon()

[Marc-André Lureau]

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/

To me, SELinux could always associate a VSOCK with a process context,
at the very least, and thus enforce some communication policies. No?

thanks

-- 
Marc-André Lureau

Re: VSOCK & getpeercon()

[Paul Moore]

On Sat, Jan 16, 2021 at 7:48 AM Marc-André Lureau
<marcandre.lureau@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.

-- 
paul moore
www.paul-moore.com

Re: VSOCK & getpeercon()

[Casey Schaufler]

On 1/22/2021 8:27 AM, Paul Moore wrote:
> On Sat, Jan 16, 2021 at 7:48 AM Marc-André Lureau
> <marcandre.lureau@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

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@vger.kernel.org> in discussions like this.

>

Re: VSOCK & getpeercon()

[Paul Moore]

On Fri, Jan 22, 2021 at 12:13 PM Casey Schaufler <casey@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@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@vger.kernel.org> in discussions like this.

-- 
paul moore
www.paul-moore.com