On 06/14/2017 03:44 PM, John Johansen wrote:

On 06/14/2017 09:06 AM, Casey Schaufler wrote:

quoted

On 6/14/2017 4:44 AM, Simon McVittie wrote:

quoted

On Tue, 13 Jun 2017 at 11:56:00 -0700, Casey Schaufler wrote:

quoted

On 6/13/2017 10:45 AM, Simon McVittie wrote:

quoted

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.

quoted

quoted

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.

quoted

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?

quoted

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