Is there a generic LSM/kernel ABI analogous to getcon_raw() and aa_getcon()?

Is there a generic LSM/kernel ABI analogous to getcon_raw() and aa_getcon()?

[Simon McVittie]

As I mentioned in a thread a while ago, I'm trying to reduce the amount
of LSM-specific code (that does very similar things for different LSMs)
in dbus-daemon, in favour of LSM-agnostic APIs. So we now have an IPC
call (method call) GetConnectionCredentials(), which one D-Bus client can
use to ask dbus-daemon for the LSM label (and other credential-like
attributes) of any other D-Bus client, and it's defined in terms of the
result of the SO_PEERSEC getsockopt. A D-Bus service (a client of the
dbus-daemon) would typically make that call as a response to getting a
request, so that it can use the uid, pid and/or LSM label to decide
whether to obey or reject the request.

Services can't just use SO_PEERSEC directly, because D-Bus is a star
topology: everything communicates only with the dbus-daemon, which
acts as a hub/broker and passes on messages. That's why we have to
offer an IPC call by which the dbus-daemon will do the SO_PEERSEC
query on the caller's behalf.

In particular, systemd is one such D-Bus service, and when it gets a
request while SELinux is enabled, it fetches some information about
the initiator.

This works fine for most clients of systemd. However, there is one
situation in which the dbus-daemon itself sends method call messages,
so we need to be prepared to respond to GetConnectionCredentials()
for the special sender name used on messages from the dbus-daemon itself,
org.freedesktop.DBus.

For specific LSMs, we can do this: libselinux and libapparmor
both have function calls that wrap a read from /proc/self/current/attr[1].
However, I'm really keen to keep GetConnectionCredentials() LSM-agnostic:
using libselinux and libapparmor wouldn't cover Smack or new LSMs,
and anyway libapparmor doesn't offer an API to get the raw label,
only a parsed form (with no documented way to compose the parts into
something equivalent to the result of SO_PEERSEC).

My next attempt was to read /proc/self/current/attr, but that doesn't
seem to be guaranteed to be consistent with SO_PEERSEC: in AppArmor,
the result of SO_PEERSEC is a bare string but /proc/self/current/attr
has a newline.

I also tried making a temporary socketpair() and doing SO_PEERSEC on that,
but at least SELinux (possibly other LSMs) doesn't really support
SO_PEERSEC on a socketpair().

Is there an LSM-agnostic API for this? My goal here is that
if we have a chain of communication
(kernel -> AF_UNIX service -> ... -> ultimate requester) and the
ultimate requester wants to see the LSM label, the only LSM-specifics
needed are in the kernel and the ultimate requester, and the rest can
pass through LSM-agnostic bytestrings without special knowledge.

Can I safely assume that, as a matter of LSM-agnostic kernel ABI, the
contents of /proc/self/current/attr are in some sense compatible with the
contents of SO_PEERSEC? (As a minimum, that they come from the same
"namespace" - for instance, for my purposes it would be bad if one had
some sort of quoting or prefix and the other didn't)

Can I safely assume that, as a matter of LSM-agnostic kernel ABI,
any trailing newlines on /proc/self/current/attr are merely a presentation
hint and can safely be stripped? What about other trailing whitespace?

Are there any other useful guarantees or equivalences that I can rely on
for arbitrary LSMs?

I was amused to see that on my AppArmor test system, ps -Z puts AppArmor
labels in the SELinux label column; it calls into libselinux, but
the way in which it uses libselinux doesn't seem to check whether SELinux
is actually active or not, and just blindly reads /proc/self/current/attr.
But ps strips all non-printable characters, which is fine for display
but not something I would be prepared to do in an API, unless this list's
consensus is that LSM labels are guaranteed to be isprint()-compliant.

Thanks,
    S

[1] actually there are some subtleties involving the current task/thread,
    but dbus-daemon is essentially single-threaded, so we can make the
    simplifying assumption that the main thread is the right one
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Is there a generic LSM/kernel ABI analogous to getcon_raw() and aa_getcon()?

[Casey Schaufler]

On 6/13/2017 10:45 AM, Simon McVittie wrote:
> As I mentioned in a thread a while ago, I'm trying to reduce the amount
> of LSM-specific code (that does very similar things for different LSMs)
> in dbus-daemon, in favour of LSM-agnostic APIs. So we now have an IPC
> call (method call) GetConnectionCredentials(), which one D-Bus client can
> use to ask dbus-daemon for the LSM label (and other credential-like
> attributes) of any other D-Bus client, and it's defined in terms of the
> result of the SO_PEERSEC getsockopt. A D-Bus service (a client of the
> dbus-daemon) would typically make that call as a response to getting a
> request, so that it can use the uid, pid and/or LSM label to decide
> whether to obey or reject the request.
>
> Services can't just use SO_PEERSEC directly, because D-Bus is a star
> topology: everything communicates only with the dbus-daemon, which
> acts as a hub/broker and passes on messages. That's why we have to
> offer an IPC call by which the dbus-daemon will do the SO_PEERSEC
> query on the caller's behalf.
>
> In particular, systemd is one such D-Bus service, and when it gets a
> request while SELinux is enabled, it fetches some information about
> the initiator.
>
> This works fine for most clients of systemd. However, there is one
> situation in which the dbus-daemon itself sends method call messages,
> so we need to be prepared to respond to GetConnectionCredentials()
> for the special sender name used on messages from the dbus-daemon itself,
> org.freedesktop.DBus.
>
> For specific LSMs, we can do this: libselinux and libapparmor
> both have function calls that wrap a read from /proc/self/current/attr[1].

I assume you mean /proc/self/attr/current

> However, I'm really keen to keep GetConnectionCredentials() LSM-agnostic:
> using libselinux and libapparmor wouldn't cover Smack or new LSMs,

Nor should they. 

There is a smack_new_label_from_self() in libsmack, which is maintained at:

	https://github.com/smack-team/smack

> and anyway libapparmor doesn't offer an API to get the raw label,
> only a parsed form (with no documented way to compose the parts into
> something equivalent to the result of SO_PEERSEC).
>
> My next attempt was to read /proc/self/current/attr, but that doesn't
> seem to be guaranteed to be consistent with SO_PEERSEC: in AppArmor,
> the result of SO_PEERSEC is a bare string but /proc/self/current/attr
> has a newline.
>
> I also tried making a temporary socketpair() and doing SO_PEERSEC on that,
> but at least SELinux (possibly other LSMs) doesn't really support
> SO_PEERSEC on a socketpair().
>
> Is there an LSM-agnostic API for this? My goal here is that
> if we have a chain of communication
> (kernel -> AF_UNIX service -> ... -> ultimate requester) and the
> ultimate requester wants to see the LSM label, the only LSM-specifics
> needed are in the kernel and the ultimate requester, and the rest can
> pass through LSM-agnostic bytestrings without special knowledge.

No.

> Can I safely assume that, as a matter of LSM-agnostic kernel ABI, the
> contents of /proc/self/current/attr are in some sense compatible with the
> contents of SO_PEERSEC? (As a minimum, that they come from the same
> "namespace" - for instance, for my purposes it would be bad if one had
> some sort of quoting or prefix and the other didn't)

A security module can support /proc/self/attr/current and/or SO_PEERSEC
any way it likes. There is no guarantee that what shows up in SO_PEERSEC
is in any way related to what's in the current file, although that is
the convention.

You also need to be aware that there is work ongoing to allow
multiple modules that currently provide these facilities to work
at the same time. That work could make your efforts both easier
and harder.

> Can I safely assume that, as a matter of LSM-agnostic kernel ABI,
> any trailing newlines on /proc/self/current/attr are merely a presentation
> hint and can safely be stripped? What about other trailing whitespace?

Discussions about how to create a combined security label string
have been held, and my recollection is that the consensus is that
trailing whitespace, including newlines, can be safely ignored.

> Are there any other useful guarantees or equivalences that I can rely on
> for arbitrary LSMs?
>
> I was amused to see that on my AppArmor test system, ps -Z puts AppArmor
> labels in the SELinux label column; it calls into libselinux, but
> the way in which it uses libselinux doesn't seem to check whether SELinux
> is actually active or not, and just blindly reads /proc/self/current/attr.
> But ps strips all non-printable characters, which is fine for display
> but not something I would be prepared to do in an API, unless this list's
> consensus is that LSM labels are guaranteed to be isprint()-compliant.
>
> Thanks,
>     S
>
> [1] actually there are some subtleties involving the current task/thread,
>     but dbus-daemon is essentially single-threaded, so we can make the
>     simplifying assumption that the main thread is the right one
> --
> To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Is there a generic LSM/kernel ABI analogous to getcon_raw() and aa_getcon()?

[Simon McVittie]

On Tue, 13 Jun 2017 at 11:56:00 -0700, Casey Schaufler wrote:
> On 6/13/2017 10:45 AM, Simon McVittie wrote:
> > For specific LSMs, we can do this: libselinux and libapparmor
> > both have function calls that wrap a read from /proc/self/current/attr[1].
> 
> I assume you mean /proc/self/attr/current

You assume correctly.

> > However, I'm really keen to keep GetConnectionCredentials() LSM-agnostic:
> > using libselinux and libapparmor wouldn't cover Smack or new LSMs,
> 
> Nor should they. 
> 
> There is a smack_new_label_from_self() in libsmack, which is maintained at:
> 
> 	https://github.com/smack-team/smack

That works up to a point, but I hope you can see why this doesn't
really scale very well! For LSMs that are less widespread than SELinux
and AppArmor, we get an unappealing choice between writing and supporting
new LSM-specific code for each LSM, or ignoring those LSMs.

We already don't really have enough SELinux expertise among the active
dbus maintainers for that part to be a first-class citizen, and we only
have AppArmor knowledge because I happen to be using it in another
project, so I'd be very reluctant to add new LSM-specifics without
someone from the relevant LSM committing to being available to
support it.

That's why LinuxSecurityLabel in the result of GetConnectionCredentials()
is defined in terms of SO_PEERSEC, so we can delegate the exact behaviour
to the Linux kernel and LSM maintainers - whatever happens to that socket
option in future LSM development, that's what we make available to clients.
The SELinux support in dbus-daemon (from Fedora/Red Hat) came first,
and I think it may have been the only widespread LSM at the time; but for
the AppArmor support (from Ubuntu) I insisted on generalizing the parts
that could be generalized.

If the kernel/LSMs don't offer a reliable way to find out our own
security label in a form compatible with SO_PEERSEC, then we might have
to just not offer that to clients either.

> You also need to be aware that there is work ongoing to allow
> multiple modules that currently provide these facilities to work
> at the same time. That work could make your efforts both easier
> and harder.

How does this work in SO_PEERSEC? If the result is a "bytestring"
(like a path or environment variable - 0 or more bytes other than '\0',
followed by a '\0' terminator, with length considered to be either
strlen(x) or strlen(x)+1) then dbus-daemon will continue to pass it
through faithfully, without needing to parse or understand it.

Obviously, the eventual consumer of this information (the D-Bus service,
in this case systemd) will need LSM-specific code to parse the forwarded
SO_PEERSEC result and use it in their security rules, and that code
would need to use a suitably updated libselinux or similar that can
parse out just the SELinux label from a stack of labels; but they'd
need those LSM-specifics to make an informed policy decision anyway.
So the LSM-specifics are confined to just the producer (the kernel)
and the eventual consumer (systemd or whatever other service).

Thanks,
    S
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Is there a generic LSM/kernel ABI analogous to getcon_raw() and aa_getcon()?

[Casey Schaufler]

On 6/14/2017 4:44 AM, Simon McVittie wrote:
> On Tue, 13 Jun 2017 at 11:56:00 -0700, Casey Schaufler wrote:
>> On 6/13/2017 10:45 AM, Simon McVittie wrote:
>>> For specific LSMs, we can do this: libselinux and libapparmor
>>> both have function calls that wrap a read from /proc/self/current/attr[1].
>> I assume you mean /proc/self/attr/current
> You assume correctly.
>
>>> However, I'm really keen to keep GetConnectionCredentials() LSM-agnostic:
>>> using libselinux and libapparmor wouldn't cover Smack or new LSMs,
>> Nor should they. 
>>
>> There is a smack_new_label_from_self() in libsmack, which is maintained at:
>>
>> 	https://github.com/smack-team/smack
> That works up to a point, but I hope you can see why this doesn't
> really scale very well! For LSMs that are less widespread than SELinux
> and AppArmor, we get an unappealing choice between writing and supporting
> new LSM-specific code for each LSM, or ignoring those LSMs.

Thank you for taking on the mantle of the bold pioneer who is
(finally) working on the LSM API. You are very brave.

One of your greatest challenges will be fending off the people
who believe that you're done once you support their favorite
security module. If it's going to be a proper LSM API it's got
to support all the existing modules and provide design guidance
to someone creating a new module. I assume that you knew the job
was dangerous when you took it.

Consider the option of eschewing the existing module specific APIs
and going directly to /proc/self/attr/current and SO_PEERSEC.

> We already don't really have enough SELinux expertise among the active
> dbus maintainers for that part to be a first-class citizen, and we only
> have AppArmor knowledge because I happen to be using it in another
> project, so I'd be very reluctant to add new LSM-specifics without
> someone from the relevant LSM committing to being available to
> support it.

Thank you for asking. How do I get on your list?

> That's why LinuxSecurityLabel in the result of GetConnectionCredentials()
> is defined in terms of SO_PEERSEC, so we can delegate the exact behaviour
> to the Linux kernel and LSM maintainers - whatever happens to that socket
> option in future LSM development, that's what we make available to clients.

The issue is that /proc/.../current doesn't give you the same thing as
SO_PEERSEC? Or that the format of what comes out of one isn't the same
as what comes out of the other? I'm a little confused about what problem
you are solving by using GetConnectionCredentials() instead of reading
/proc/.../current

> The SELinux support in dbus-daemon (from Fedora/Red Hat) came first,
> and I think it may have been the only widespread LSM at the time; but for
> the AppArmor support (from Ubuntu) I insisted on generalizing the parts
> that could be generalized.

General being something other than a text string?

> If the kernel/LSMs don't offer a reliable way to find out our own
> security label in a form compatible with SO_PEERSEC, then we might have
> to just not offer that to clients either.

 
Upstream only SELinux and Smack provide both /proc/.../current
and SO_PEERSEC. They provide label strings that can be compared.
AppArmor does not support SO_PEERSEC as of 4.12. So as of today,
there isn't a problem. Or am I missing something?



>> You also need to be aware that there is work ongoing to allow
>> multiple modules that currently provide these facilities to work
>> at the same time. That work could make your efforts both easier
>> and harder.
> How does this work in SO_PEERSEC? If the result is a "bytestring"
> (like a path or environment variable - 0 or more bytes other than '\0',
> followed by a '\0' terminator, with length considered to be either
> strlen(x) or strlen(x)+1) then dbus-daemon will continue to pass it
> through faithfully, without needing to parse or understand it.

What I've proposed in the past in a string like:

	selinux="mumble_t",smack="Mumble",apparmor="aa_mumble"

This has a problem with AppArmor's use of newlines, but we had
discussions that led me to believe this is surmountable.

An option which I have been investigating is to add a
sockopt to specify which security module's data you want
getsockopt(..., SO_PEERSEC, ...) to provide. If you haven't
specified, you get the first available (per the wishes of the
SELinux crowd). If you specify an LSM name you get the value
for that. If you specify "context" you get the wacky string
with all the available modules. I'm leaning in this direction
because it should be easier on the existing userspace. Only
those that are aware of the possibility of multiple security
modules need to be modified.

> Obviously, the eventual consumer of this information (the D-Bus service,
> in this case systemd) will need LSM-specific code to parse the forwarded
> SO_PEERSEC result and use it in their security rules, and that code
> would need to use a suitably updated libselinux or similar that can
> parse out just the SELinux label from a stack of labels; but they'd
> need those LSM-specifics to make an informed policy decision anyway.
> So the LSM-specifics are confined to just the producer (the kernel)
> and the eventual consumer (systemd or whatever other service).
>
> Thanks,
>     S
>

--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Is there a generic LSM/kernel ABI analogous to getcon_raw() and aa_getcon()?

[John Johansen]

On 06/14/2017 09:06 AM, Casey Schaufler wrote:
> On 6/14/2017 4:44 AM, Simon McVittie wrote:
>> On Tue, 13 Jun 2017 at 11:56:00 -0700, Casey Schaufler wrote:
>>> On 6/13/2017 10:45 AM, Simon McVittie wrote:
>>>> For specific LSMs, we can do this: libselinux and libapparmor
>>>> both have function calls that wrap a read from /proc/self/current/attr[1].
>>> I assume you mean /proc/self/attr/current
>> You assume correctly.
>>
>>>> However, I'm really keen to keep GetConnectionCredentials() LSM-agnostic:
>>>> using libselinux and libapparmor wouldn't cover Smack or new LSMs,
>>> Nor should they. 
>>>
>>> There is a smack_new_label_from_self() in libsmack, which is maintained at:
>>>
>>> 	https://github.com/smack-team/smack
>> That works up to a point, but I hope you can see why this doesn't
>> really scale very well! For LSMs that are less widespread than SELinux
>> and AppArmor, we get an unappealing choice between writing and supporting
>> new LSM-specific code for each LSM, or ignoring those LSMs.
> 
> Thank you for taking on the mantle of the bold pioneer who is
> (finally) working on the LSM API. You are very brave.
> 
> One of your greatest challenges will be fending off the people
> who believe that you're done once you support their favorite
> security module. If it's going to be a proper LSM API it's got
> to support all the existing modules and provide design guidance
> to someone creating a new module. I assume that you knew the job
> was dangerous when you took it.
> 
> Consider the option of eschewing the existing module specific APIs
> and going directly to /proc/self/attr/current and SO_PEERSEC.
> 
>> We already don't really have enough SELinux expertise among the active
>> dbus maintainers for that part to be a first-class citizen, and we only
>> have AppArmor knowledge because I happen to be using it in another
>> project, so I'd be very reluctant to add new LSM-specifics without
>> someone from the relevant LSM committing to being available to
>> support it.
> 
> Thank you for asking. How do I get on your list?
> 
>> That's why LinuxSecurityLabel in the result of GetConnectionCredentials()
>> is defined in terms of SO_PEERSEC, so we can delegate the exact behaviour
>> to the Linux kernel and LSM maintainers - whatever happens to that socket
>> option in future LSM development, that's what we make available to clients.
> 
> The issue is that /proc/.../current doesn't give you the same thing as
> SO_PEERSEC? Or that the format of what comes out of one isn't the same
> as what comes out of the other? I'm a little confused about what problem
> you are solving by using GetConnectionCredentials() instead of reading
> /proc/.../current
> 
dbus is a userspace acts as a userspace proxy

A <===> dbus <====> B

A wants to know the credentials of B. GetConnectionCredentials() is
essentially the dbus equiv of using SO_PEERSEC in the situation of

A <===> B


>> The SELinux support in dbus-daemon (from Fedora/Red Hat) came first,
>> and I think it may have been the only widespread LSM at the time; but for
>> the AppArmor support (from Ubuntu) I insisted on generalizing the parts
>> that could be generalized.
> 
> General being something other than a text string?
> 
>> If the kernel/LSMs don't offer a reliable way to find out our own
>> security label in a form compatible with SO_PEERSEC, then we might have
>> to just not offer that to clients either.
> 
>  
> Upstream only SELinux and Smack provide both /proc/.../current
> and SO_PEERSEC. They provide label strings that can be compared.
> AppArmor does not support SO_PEERSEC as of 4.12. So as of today,
> there isn't a problem. Or am I missing something?
> 
Simon has been using kernels with Ubuntu patchset for apparmor which
does support SO_PEERSEC.

The 3.13 pull request updates the upstream code to a common base, so
you should be seeing RFCs for this stuff soon.

> 
> 
>>> You also need to be aware that there is work ongoing to allow
>>> multiple modules that currently provide these facilities to work
>>> at the same time. That work could make your efforts both easier
>>> and harder.
>> How does this work in SO_PEERSEC? If the result is a "bytestring"
>> (like a path or environment variable - 0 or more bytes other than '\0',
>> followed by a '\0' terminator, with length considered to be either
>> strlen(x) or strlen(x)+1) then dbus-daemon will continue to pass it
>> through faithfully, without needing to parse or understand it.
> 
> What I've proposed in the past in a string like:
> 
> 	selinux="mumble_t",smack="Mumble",apparmor="aa_mumble"
> 
> This has a problem with AppArmor's use of newlines, but we had
> discussions that led me to believe this is surmountable.
> 
I am trying to get rid of those, and force tightening of the spec.
We are also moving the write end of our set_execon equiv away
from the proc interface so that won't be the issue it was in the
past

> An option which I have been investigating is to add a
> sockopt to specify which security module's data you want
> getsockopt(..., SO_PEERSEC, ...) to provide. If you haven't
> specified, you get the first available (per the wishes of the
> SELinux crowd). If you specify an LSM name you get the value
> for that. If you specify "context" you get the wacky string
> with all the available modules. I'm leaning in this direction
> because it should be easier on the existing userspace. Only
> those that are aware of the possibility of multiple security
> modules need to be modified.
> 
>> Obviously, the eventual consumer of this information (the D-Bus service,
>> in this case systemd) will need LSM-specific code to parse the forwarded
>> SO_PEERSEC result and use it in their security rules, and that code
>> would need to use a suitably updated libselinux or similar that can
>> parse out just the SELinux label from a stack of labels; but they'd
>> need those LSM-specifics to make an informed policy decision anyway.
>> So the LSM-specifics are confined to just the producer (the kernel)
>> and the eventual consumer (systemd or whatever other service).
>>
>> Thanks,
>>     S
>>
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Is there a generic LSM/kernel ABI analogous to getcon_raw() and aa_getcon()?

[John Johansen]

On 06/14/2017 03:44 PM, John Johansen wrote:
> On 06/14/2017 09:06 AM, Casey Schaufler wrote:
>> On 6/14/2017 4:44 AM, Simon McVittie wrote:
>>> On Tue, 13 Jun 2017 at 11:56:00 -0700, Casey Schaufler wrote:
>>>> On 6/13/2017 10:45 AM, Simon McVittie wrote:
>>>>> For specific LSMs, we can do this: libselinux and libapparmor
>>>>> both have function calls that wrap a read from /proc/self/current/attr[1].
>>>> I assume you mean /proc/self/attr/current
>>> You assume correctly.
>>>
>>>>> However, I'm really keen to keep GetConnectionCredentials() LSM-agnostic:
>>>>> using libselinux and libapparmor wouldn't cover Smack or new LSMs,
>>>> Nor should they. 
>>>>
>>>> There is a smack_new_label_from_self() in libsmack, which is maintained at:
>>>>
>>>> 	https://github.com/smack-team/smack
>>> That works up to a point, but I hope you can see why this doesn't
>>> really scale very well! For LSMs that are less widespread than SELinux
>>> and AppArmor, we get an unappealing choice between writing and supporting
>>> new LSM-specific code for each LSM, or ignoring those LSMs.
>>
>> Thank you for taking on the mantle of the bold pioneer who is
>> (finally) working on the LSM API. You are very brave.
>>
>> One of your greatest challenges will be fending off the people
>> who believe that you're done once you support their favorite
>> security module. If it's going to be a proper LSM API it's got
>> to support all the existing modules and provide design guidance
>> to someone creating a new module. I assume that you knew the job
>> was dangerous when you took it.
>>
>> Consider the option of eschewing the existing module specific APIs
>> and going directly to /proc/self/attr/current and SO_PEERSEC.
>>
>>> We already don't really have enough SELinux expertise among the active
>>> dbus maintainers for that part to be a first-class citizen, and we only
>>> have AppArmor knowledge because I happen to be using it in another
>>> project, so I'd be very reluctant to add new LSM-specifics without
>>> someone from the relevant LSM committing to being available to
>>> support it.
>>
>> Thank you for asking. How do I get on your list?
>>
>>> That's why LinuxSecurityLabel in the result of GetConnectionCredentials()
>>> is defined in terms of SO_PEERSEC, so we can delegate the exact behaviour
>>> to the Linux kernel and LSM maintainers - whatever happens to that socket
>>> option in future LSM development, that's what we make available to clients.
>>
>> The issue is that /proc/.../current doesn't give you the same thing as
>> SO_PEERSEC? Or that the format of what comes out of one isn't the same
>> as what comes out of the other? I'm a little confused about what problem
>> you are solving by using GetConnectionCredentials() instead of reading
>> /proc/.../current
>>
> dbus is a userspace acts as a userspace proxy
> 
> A <===> dbus <====> B
> 
> A wants to know the credentials of B. GetConnectionCredentials() is
> essentially the dbus equiv of using SO_PEERSEC in the situation of
> 
> A <===> B
> 
> 
And for this situation it makes sense to pass the output of using SO_PEERSEC
directly and not using the lsm api's.

I know its a little more complicated than that in that them LSM specific
extensions are also doing things and directly poking at /proc/ and
SO_PEERSEC.

And of course I haven't followed enough to know how else Simon wants
to use this info.

I can say from the apparmor end we aren't using the troublesome trailing
\n\0 (at least at the api) and those can be thrown away without
affecting the dbus apprmor dbus code.

I haven't been able to find my notes on why I had leave that trailing
garbage in back in 2009.
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Is there a generic LSM/kernel ABI analogous to getcon_raw() and aa_getcon()?

[Simon McVittie]

On Wed, 14 Jun 2017 at 09:06:38 -0700, Casey Schaufler wrote:
> If it's going to be a proper LSM API it's got
> to support all the existing modules and provide design guidance
> to someone creating a new module.

This is what I was trying to avoid by having the D-Bus API be defined
in terms of things the kernel already provides, such that any new LSM
that would break dbus-daemon would already be breaking the existing
kernel APIs, and so can safely be ignored :-)

> Consider the option of eschewing the existing module specific APIs
> and going directly to /proc/self/attr/current and SO_PEERSEC.

That's what I did for what we have so far (SO_PEERSEC). The issue I have
is that reading my own /proc/self/attr/current, and a peer who is connected
to me by a socket asking the kernel who I am using SO_PEERSEC, don't seem
to be guaranteed to produce compatible results.

> > We already don't really have enough SELinux expertise among the active
> > dbus maintainers for that part to be a first-class citizen, and we only
> > have AppArmor knowledge because I happen to be using it in another
> > project, so I'd be very reluctant to add new LSM-specifics without
> > someone from the relevant LSM committing to being available to
> > support it.
> 
> Thank you for asking. How do I get on your list?

What LSM support do you want to contribute to dbus?

At the moment my strategy for asking for information on this topic is
to contact this list. If there are some people on this list with
freedesktop.org Bugzilla accounts who I can cc on relevant bug reports
and feature requests to act as an LSM spokesperson, that would be great.

If you're looking to contribute new code that isn't already there (or
audit what we already have), broadly, there are two-and-a-bit ways in
which LSMs are used in dbus-daemon:

Identification
==============

In a direct AF_UNIX connection

           AF_UNIX
    server a<==c client    a: result of accept()ing
         <---------        c: the end that connect()ed
          request
         --------->
          response

the server can use SO_PEERSEC to ask the kernel who the client is.
On D-Bus, because we have a "man in the middle", the dbus-daemon
(aka message bus or broker):

           AF_UNIX           AF_UNIX
    service c==>a dbus-daemon a<==c client
          <--------------------------
                    request
          -------------------------->
                    response

the service does not have a direct connection to the client, so there
is no way for the service to ask the kernel who the client is
(uid, pid, LSM label). So we have IPC APIs by which the service can ask
dbus-daemon for that information instead; the dbus-daemon is directly
connected to the client, so the dbus-daemon *can* get that information
from the kernel.

Because this is security-sensitive, we have to be careful about how
we get this information - the existence of setuid and similar mechanisms
to escalate privilege across exec() while keeping the same pid, and the
existence of pid wrap-around, mean that anything based on "get the pid
of the peer, then get the credentials of that process by looking up its
pid" is unsafe. SO_PEERCRED and SO_PEERSEC are ideal, though, because
they store what the credentials were at the time the socket was
opened (I forget whether it's socket() or connect() that matters,
but either would do for our purposes). If you are the process that
opened a socket and connected it to the dbus-daemon, then you are
considered to be responsible for not letting less-trusted users/contexts
use that socket.

Based on our previous discussion on this list, I believe
GetConnectionCredentials() does this in a way that is generic across
all LSMs - the service still needs to understand what the current LSM(s)
put in SO_PEERSEC in order to make any sensible auth decision, but
the dbus-daemon can just pass this information through without
being required to understand it.

When I added LinuxSecurityLabel to GetConnectionCredentials(), I
checked it with this list. That was a response to two different people
wanting to add GetConnectionSmackContext() for Smack, and
GetConnectionAppArmorLabel() for AppArmor, in addition to our
existing GetConnectionSELinuxContext() - which is clearly at least
two methods too many, given that they are all basically SO_PEERSEC
behind the scenes.

So if you only want the identification feature for dbus on Smack
systems, I think we already have that, without needing to write or
support any code that isn't already shared by other LSMs. The same
is hopefully true for all current and future LSMs (or at least
those with SO_PEERSEC).

Self-identification
-------------------

The problem that I'm trying to solve right now is a special case
of identification. On the D-Bus message bus, we have a naming scheme
for talking about connections, so that the service can identify which
client it is asking about. This naming scheme has a special reserved
name for the dbus-daemon itself, so it is syntactically possible to
ask that question, and it is unexpected if that question doesn't get
a sensible answer. At the moment, asking for the credentials
of the dbus-daemon just doesn't return a LSM label (indicating
"unknown" or "not applicable"), but that's an unexpected special case.
What we would identically like is for the dbus-daemon to return the
same thing that the client would have got by getting the SO_PEERSEC
socket option from its connection to the dbus-daemon.

Because the dbus-daemon does not have an AF_UNIX socket connected to
itself, we can't use SO_PEERSEC directly, hence me looking into using
/proc/self/attr/current. We can't safely use /proc/$pid/attr/current
for an arbitrary other process, because the other process might be
maliciously causing race conditions that would trick us (below) - but we
can use it for /proc/self, because we trust ourselves not to do such things.

Mediation
=========

Some LSM users/developers want the dbus-daemon to filter messages
as they go through it, preventing clients with label A from communicating
with services with label B. We have this code for SELinux (contributed
by Red Hat/Fedora, long before my involvement) and for AppArmor (originating
from Ubuntu/Canonical, with some modifications from me). At some point
in the past there was a feature request to add similar mediation for
Smack, contributed by Tizen/Intel/Samsung people
<https://bugs.freedesktop.org/show_bug.cgi?id=47581> but the proposed
patches were later withdrawn since their authors didn't need that
part any more, only identification.

If you or your Smack-using colleagues want to resurrect that feature
request so that the dbus-daemon can accept or reject messages based on
Smack labels, the dbus at lists.freedesktop.org mailing list is suitable
for general discussion, and freedesktop.org Bugzilla is where we do
detailed patch review. The reviews on #47581 are probably relevant, so
I would advise skim-reading those first.

The same goes for other LSMs: as far as I'm aware, we cannot support
this generically, and mediation always requires LSM-specific code for
each LSM. In general we can't fix bugs (or test fixes) in that
LSM-specific code, so to add new code for mediation we would need
someone we can assign those bugs to.

> The issue is that /proc/.../current doesn't give you the same thing as
> SO_PEERSEC? Or that the format of what comes out of one isn't the same
> as what comes out of the other? I'm a little confused about what problem
> you are solving by using GetConnectionCredentials() instead of reading
> /proc/.../current

Suppose you are some service like NetworkManager, you have been contacted
via D-Bus by a process that claims to be uid 1000's gnome-shell, and you
want to know whether they should be allowed to connect to a different
network or something.

You can't use SO_PEERSEC or SO_PEERCRED yourself, because the way D-Bus
works, you are not directly connected to that process - there is a
dbus-daemon in the middle forwarding messages. So you have to ask the
dbus-daemon who they are instead. D-Bus is a message-passing IPC system
(with some syntactic sugar to make request/response pairs look vaguely
like object-oriented method calls, analogous to other RPC-style protocols),
so for communication directly with the dbus-daemon, we have some messages
that are processed inside the dbus-daemon instead of being forwarded
elsewhere. GetConnectionCredentials() is one of those messages.

You also can't get the process ID (let's say 1234) from dbus-daemon
and then look in /proc/1234/attr, because a malicious caller might
exec() a process that gets higher privileges than their own (racing with
the service in the hope that the exec() will happen before the
access-control check); or, more speculatively, a malicious caller might
_exit() at exactly the right time that their pid is reused by a new
process with higher privileges than theirs (again racing with the service).

> > The SELinux support in dbus-daemon (from Fedora/Red Hat) came first,
> > and I think it may have been the only widespread LSM at the time; but for
> > the AppArmor support (from Ubuntu) I insisted on generalizing the parts
> > that could be generalized.
> 
> General being something other than a text string?

General being: instead of having

- GetConnectionSELinuxContext(string: connection) -> UTF-8 string (?) or error
- GetConnectionAppArmorLabel(string: connection) -> bytestring or error
- GetConnectionSmackContext(string: connection) -> bytestring (?) or error
- GetConnectionMyNewModuleContext(string: conn) -> UTF-8 string or error
- GetConnectionYourNewModuleContext(string: conn) -> 64-bit integer or error

and having to write and maintain specific code for each one, we would
much prefer to have a single code path, and delegate interpretation of
the result to code that needs to be specific to a particular LSM anyway.
(Similar to the way the Linux kernel has SO_PEERSEC and all the LSMs share
it, rather than having SO_PEERSELINUX, SO_PEERAPPARMOR, SO_PEERSMACK...)

> Upstream only SELinux and Smack provide both /proc/.../current
> and SO_PEERSEC. They provide label strings that can be compared.
> AppArmor does not support SO_PEERSEC as of 4.12. So as of today,
> there isn't a problem. Or am I missing something?

What I would need, in order to do what I had hoped, would be a general
statement from the LSM (infrastructure) maintainers something along the
lines of: "If an LSM has labels in both /proc/.../current and SO_PEERSEC
and they differ, then that LSM is wrong and can safely be ignored". Or,
perhaps: "If an LSM has labels in /proc/.../current that end with a
newline, normalizing by stripping that newline does not change the
meaning; and if the label in /proc/.../current (after stripping a possible
newline) differs from the label in SO_PEERSEC, then that LSM is wrong
and can safely be ignored".

(Similar to the way my last thread on this list ended with consensus
that whether an LSM label in SO_PEERSEC includes a "\0" in its length
or not is not significant, and normalizing by adding or removing a
single trailing "\0" does not change the meaning.)

> An option which I have been investigating is to add a
> sockopt to specify which security module's data you want
> getsockopt(..., SO_PEERSEC, ...) to provide. If you haven't
> specified, you get the first available (per the wishes of the
> SELinux crowd). If you specify an LSM name you get the value
> for that. If you specify "context" you get the wacky string
> with all the available modules. I'm leaning in this direction
> because it should be easier on the existing userspace. Only
> those that are aware of the possibility of multiple security
> modules need to be modified.

Hmm. GetConnectionCredentials() returns a data stucture like this:

    { "UnixUserID" => 1000, "ProcessID" => 1234,
      "LinuxSecurityLabel" => "whatever_SO_PEERSEC_said\0" }

which is extensible: we can add or remove whatever string keys we want
(for instance on Windows there's no UnixUserID or LinuxSecurityLabel,
but instead there's WindowsSID for the Windows analogue of a uid),
and a particular string not appearing means "unknown or not applicable"
(for instance LinuxSecurityLabel doesn't appear unless you are on
Linux and have some suitable LSM loaded).

So we have three options for dealing with your new multiplexed strings:

* LinuxSecurityLabel is the first available and is deprecated, and a
  new LinuxSecurityLabels is the multiplexed string
* LinuxSecurityLabel is the first available and is deprecated, and
  the string is parsed (in an LSM-agnostic way) to produce
  "LinuxSecurityLabel.selinux" => "whatever_t\0",
  "LinuxSecurityLabel.apparmor" => "/usr/bin/whatever\0" and so on
  (or a nested mapping { "selinux" => "whatever_t\0", ... } maybe)
* LinuxSecurityLabel is the multiplexed string, and recipients are
  expected to evolve to deal with it

Either way, I would hope that libselinux, libapparmor, libsmack
etc. would eventually be updated so that functions like AppArmor's
aa_splitcon() are able to parse the multiplexed string and discard all
the parts not relevant to this specific LSM?

    S
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Is there a generic LSM/kernel ABI analogous to getcon_raw() and aa_getcon()?

[John Johansen]

On 06/16/2017 09:13 AM, Simon McVittie wrote:
> On Wed, 14 Jun 2017 at 09:06:38 -0700, Casey Schaufler wrote:

> 
>> Upstream only SELinux and Smack provide both /proc/.../current
>> and SO_PEERSEC. They provide label strings that can be compared.
>> AppArmor does not support SO_PEERSEC as of 4.12. So as of today,
>> there isn't a problem. Or am I missing something?
> 
> What I would need, in order to do what I had hoped, would be a general
> statement from the LSM (infrastructure) maintainers something along the
> lines of: "If an LSM has labels in both /proc/.../current and SO_PEERSEC
> and they differ, then that LSM is wrong and can safely be ignored". Or,
> perhaps: "If an LSM has labels in /proc/.../current that end with a
> newline, normalizing by stripping that newline does not change the
> meaning; and if the label in /proc/.../current (after stripping a possible
> newline) differs from the label in SO_PEERSEC, then that LSM is wrong
> and can safely be ignored".
> 
> (Similar to the way my last thread on this list ended with consensus
> that whether an LSM label in SO_PEERSEC includes a "\0" in its length
> or not is not significant, and normalizing by adding or removing a
> single trailing "\0" does not change the meaning.)
> 
This is possibly a constraint that could be agreed on and added. Currently
only 3 lsms (selinux, smack, apparmor) use the getprocattr interface.
And 2 lsms upstream (selinux, smack) use SO_PEERSEC. With apparmor adding
support for it upstream soon.

>From experience, apparmor will not be adding \n to the end of the value
from SO_PEERSEC, as it broke some services. But I have been digging and
testing and it looks like we are good dropping the trailing \n from
the proc interface.

And I can state that the current output of the proc interface and
SO_PEERSEC should be the same except for the trailing \n, which
can (and is in libapparmor) thrown away.

So today we have all 3 users of the interfaces with output that meets your
requirement modulo the trailing garbage, and apparmor is going to bring
its use of proc intro compliance so that all 3 LSMs meet the requested
requirement of the output from the proc interface and SO_PEERSEC being
the same.

So while the interfaces do not currently guarantee the output of the
two interfaces is the same, since no LSMs use the interfaces
differently than requested I don't think its unreasonable to ask the
community to add the additional requirement that procgetattr and
SO_PEERSEC output match.

--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Is there a generic LSM/kernel ABI analogous to getcon_raw() and aa_getcon()?

[José Bollo]

On Fri, 16 Jun 2017 17:13:57 +0100
Simon McVittie <smcv@collabora.com> wrote:

(snip)
 
> Self-identification
> -------------------
> 
> The problem that I'm trying to solve right now is a special case
> of identification. On the D-Bus message bus, we have a naming scheme
> for talking about connections, so that the service can identify which
> client it is asking about. This naming scheme has a special reserved
> name for the dbus-daemon itself, so it is syntactically possible to
> ask that question, and it is unexpected if that question doesn't get
> a sensible answer. At the moment, asking for the credentials
> of the dbus-daemon just doesn't return a LSM label (indicating
> "unknown" or "not applicable"), but that's an unexpected special case.
> What we would identically like is for the dbus-daemon to return the
> same thing that the client would have got by getting the SO_PEERSEC
> socket option from its connection to the dbus-daemon.
> 
> Because the dbus-daemon does not have an AF_UNIX socket connected to
> itself, we can't use SO_PEERSEC directly, hence me looking into using
> /proc/self/attr/current. We can't safely use /proc/$pid/attr/current
> for an arbitrary other process, because the other process might be
> maliciously causing race conditions that would trick us (below) - but
> we can use it for /proc/self, because we trust ourselves not to do
> such things.

Hi 

If there were a SO_MYSEC doing the job you had used it. But there is no
SO_MYSEC nor SO_MYCRED.

> Mediation
> =========
> 
> Some LSM users/developers want the dbus-daemon to filter messages
> as they go through it, preventing clients with label A from
> communicating with services with label B. We have this code for
> SELinux (contributed by Red Hat/Fedora, long before my involvement)
> and for AppArmor (originating from Ubuntu/Canonical, with some
> modifications from me). At some point in the past there was a feature
> request to add similar mediation for Smack, contributed by
> Tizen/Intel/Samsung people
> <https://bugs.freedesktop.org/show_bug.cgi?id=47581> but the proposed
> patches were later withdrawn since their authors didn't need that
> part any more, only identification.

That is really interesting! I'm working for AGL (automotivelinux.org)
that use that discontinued job of SAMSUNG/TIZEN. But I had in mind that
you were not warm to intgrate the job done. The developper, Patrick
Ohly made an interesting job to allow asynchronous request to the
policy server within the dbus-daemon.

> If you or your Smack-using colleagues want to resurrect that feature
> request so that the dbus-daemon can accept or reject messages based on
> Smack labels, the dbus at lists.freedesktop.org mailing list is suitable
> for general discussion, and freedesktop.org Bugzilla is where we do
> detailed patch review. The reviews on #47581 are probably relevant, so
> I would advise skim-reading those first.

Good. Seems to be 2 years old. The case of Tizen/AGL use a policy
manager comparable to polkit. Are you developing currently a
generalisation of this?

> The same goes for other LSMs: as far as I'm aware, we cannot support
> this generically, and mediation always requires LSM-specific code for
> each LSM. In general we can't fix bugs (or test fixes) in that
> LSM-specific code, so to add new code for mediation we would need
> someone we can assign those bugs to.

But is there really a need except for dbus-daemon itself?

(snip)

> So we have three options for dealing with your new multiplexed
> strings:
> 
> * LinuxSecurityLabel is the first available and is deprecated, and a
>   new LinuxSecurityLabels is the multiplexed string
> * LinuxSecurityLabel is the first available and is deprecated, and
>   the string is parsed (in an LSM-agnostic way) to produce
>   "LinuxSecurityLabel.selinux" => "whatever_t\0",
>   "LinuxSecurityLabel.apparmor" => "/usr/bin/whatever\0" and so on
>   (or a nested mapping { "selinux" => "whatever_t\0", ... } maybe)
> * LinuxSecurityLabel is the multiplexed string, and recipients are
>   expected to evolve to deal with it

More complexity, always...

Why not just using the result of SO_PEERSEC?

Best regards
Jos? Bollo
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Is there a generic LSM/kernel ABI analogous to getcon_raw() and aa_getcon()?

[Simon McVittie]

On Fri, 23 Jun 2017 at 16:39:25 +0200, Jos? Bollo wrote:
> I'm working for AGL (automotivelinux.org)
> that use that discontinued job of SAMSUNG/TIZEN. But I had in mind that
> you were not warm to intgrate the job done. The developper, Patrick
> Ohly made an interesting job to allow asynchronous request to the
> policy server within the dbus-daemon.

I'd consider whatever patches were submitted upstream (so far, none were,
if I remember correctly) but my instinct is to say that checking policy
asynchronously might well add too much complexity to be maintainable.
The dbus-daemon is already quite complicated enough with strict in-order
processing, we should try not to make it worse :-)

> The case of Tizen/AGL use a policy
> manager comparable to polkit. Are you developing currently a
> generalisation of this?

I assume you are referring to Cynara?

The freedesktop.org approach to sysadmin-configurable policy is polkit,
which is used by having services (not the dbus-daemon) call out to it,
preferably asynchronously. That has a latency and throughput overhead,
but it has the major advantage (over anything the dbus-daemon could do)
that the operations being queried are something high-level that makes
sense to the service author (such as "mount a removable disk on a
different seat" for udisks2, which is my usual example of a polkit user).
Everything dbus-daemon knows is at the level of D-Bus message-passing
and header fields, which isn't necessarily very useful when making a
policy decision. See <http://smcv.pseudorandom.co.uk/2015/why_polkit/>
for more background on that.

dbus-daemon's only involvement in services' use of polkit is:
* reliably identifying clients of the service (uid, pid, LSM label) when
  the service asks about them, which is related to this thread
* delivering opaque messages (not understood by dbus-daemon) between all
  the components involved

I am not active in polkit development.

> > The same goes for other LSMs: as far as I'm aware, we cannot support
> > this generically, and mediation always requires LSM-specific code for
> > each LSM. In general we can't fix bugs (or test fixes) in that
> > LSM-specific code, so to add new code for mediation we would need
> > someone we can assign those bugs to.
> 
> But is there really a need except for dbus-daemon itself?

I'm not sure I understand your question here?

If people who use a particular LSM want dbus-daemon to mediate messages
according to that LSM's rules, then there needs to be code in dbus-daemon
that is both specific to dbus-daemon (not shared with whatever other
component might mediate IPC, although there is probably nothing else that
would want to), and specific to that LSM (not shared with other LSMs).

> > So we have three options for dealing with your new multiplexed
> > strings
>
> More complexity, always...
> 
> Why not just using the result of SO_PEERSEC?

That's what we do right now. However, if I'm understanding what Casey
said correctly, one of the API options under consideration is to
have a socket option that alters what SO_PEERSEC returns, which makes
"the result of SO_PEERSEC" no longer a well-defined concept - it would
be more accurate to say "*a* result of SO_PEERSEC", and we have to decide
which of the several possible results is the right one to appear on D-Bus.

(One of the options I listed was effectively "the result of SO_PEERSEC,
assuming dbus-daemon has not done anything special to select a non-default
result". That's what current dbus-daemon, 1.10.x, will return forever.)

    S
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Is there a generic LSM/kernel ABI analogous to getcon_raw() and aa_getcon()?

[John Johansen]

On 06/13/2017 10:45 AM, Simon McVittie wrote:
> As I mentioned in a thread a while ago, I'm trying to reduce the amount
> of LSM-specific code (that does very similar things for different LSMs)
> in dbus-daemon, in favour of LSM-agnostic APIs. So we now have an IPC
> call (method call) GetConnectionCredentials(), which one D-Bus client can
> use to ask dbus-daemon for the LSM label (and other credential-like
> attributes) of any other D-Bus client, and it's defined in terms of the
> result of the SO_PEERSEC getsockopt. A D-Bus service (a client of the
> dbus-daemon) would typically make that call as a response to getting a
> request, so that it can use the uid, pid and/or LSM label to decide
> whether to obey or reject the request.
> 
> Services can't just use SO_PEERSEC directly, because D-Bus is a star
> topology: everything communicates only with the dbus-daemon, which
> acts as a hub/broker and passes on messages. That's why we have to
> offer an IPC call by which the dbus-daemon will do the SO_PEERSEC
> query on the caller's behalf.
> 
> In particular, systemd is one such D-Bus service, and when it gets a
> request while SELinux is enabled, it fetches some information about
> the initiator.
> 
> This works fine for most clients of systemd. However, there is one
> situation in which the dbus-daemon itself sends method call messages,
> so we need to be prepared to respond to GetConnectionCredentials()
> for the special sender name used on messages from the dbus-daemon itself,
> org.freedesktop.DBus.
> 
> For specific LSMs, we can do this: libselinux and libapparmor
> both have function calls that wrap a read from /proc/self/current/attr[1].
> However, I'm really keen to keep GetConnectionCredentials() LSM-agnostic:
> using libselinux and libapparmor wouldn't cover Smack or new LSMs,
> and anyway libapparmor doesn't offer an API to get the raw label,
> only a parsed form (with no documented way to compose the parts into

libapparmor certainly could export the raw context, the parse splits
the context into the label and mode, however for most cases this pair
can be treated as a single entity.

> something equivalent to the result of SO_PEERSEC).
> 
the output format of /proc/self/attr/current and SO_PEERSEC are the
same, except that /proc/self/attr/current includes a trailing \n\0
for historical reasons.

Including those in SO_PEERSEC was unnecessarily and actually broke
some applications when we considered doing it for consistency.

It might be worth looking again at stripping the trailing two
bytes from the apparmor /proc/self/attr/current output. I don't
remember the details but there was an issue last time I looked
in about 2009

> My next attempt was to read /proc/self/current/attr, but that doesn't
> seem to be guaranteed to be consistent with SO_PEERSEC: in AppArmor,
> the result of SO_PEERSEC is a bare string but /proc/self/current/attr
> has a newline.
> 
correct, as mentioned above

> I also tried making a temporary socketpair() and doing SO_PEERSEC on that,
> but at least SELinux (possibly other LSMs) doesn't really support
> SO_PEERSEC on a socketpair().
> 
socket pairs are a pita with how they are currently setup, at least
from an LSM perspective as they bypass the unix_stream_connect hook

> Is there an LSM-agnostic API for this? My goal here is that
> if we have a chain of communication

sadly no

> (kernel -> AF_UNIX service -> ... -> ultimate requester) and the
> ultimate requester wants to see the LSM label, the only LSM-specifics
> needed are in the kernel and the ultimate requester, and the rest can
> pass through LSM-agnostic bytestrings without special knowledge.
> 
> Can I safely assume that, as a matter of LSM-agnostic kernel ABI, the
> contents of /proc/self/current/attr are in some sense compatible with the
> contents of SO_PEERSEC? (As a minimum, that they come from the same

there are no guarantees, though it makes sense for them to be the same

> "namespace" - for instance, for my purposes it would be bad if one had
> some sort of quoting or prefix and the other didn't)
> 
right

> Can I safely assume that, as a matter of LSM-agnostic kernel ABI,
> any trailing newlines on /proc/self/current/attr are merely a presentation
> hint and can safely be stripped? What about other trailing whitespace?
> 
this is true for apparmor, I can't speak for the other lsms

> Are there any other useful guarantees or equivalences that I can rely on
> for arbitrary LSMs?
> 
it would be nice, but no

> I was amused to see that on my AppArmor test system, ps -Z puts AppArmor
> labels in the SELinux label column; it calls into libselinux, but
> the way in which it uses libselinux doesn't seem to check whether SELinux
> is actually active or not, and just blindly reads /proc/self/current/attr.
> But ps strips all non-printable characters, which is fine for display
> but not something I would be prepared to do in an API, unless this list's
> consensus is that LSM labels are guaranteed to be isprint()-compliant.
> 
apparmor's currently aren't guaranteed to be, however they should be and
we are going to start enforcing it.
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html