Re: Early comments on kdbus v2 (Re: [PATCH 00/12] Add kdbus implementation)

[Andy Lutomirski]

On Wed, Nov 5, 2014 at 9:02 AM, Simon McVittie
 wrote:
> On 05/11/14 15:56, Andy Lutomirski wrote:
>>  - I tend to think that pid and tid should be separate.  They're
>> really their own thing, and, as noted in all the perfectly valid
>> dislike directed at SO_PEERCRED, they have extremely limited value.
>
> Traditional D-Bus has GetConnectionUnixProcessID(), which is used by
> several applications:
> ,
>  (the latter is the Qt
> binding).
>
> I don't know what those applications use it for, or whether they're
> doing it safely. CVE-2013-4288, CVE-2014-5033 seem potentially relevant.
>
> In the same way that kernel people don't want to break userland, I don't
> want to break existing D-Bus users; it would be a shame if kdbus omits
> things that would let it replace traditional D-Bus.

That's why I suggested separating it, not removing it.  If it were
separate, then short-lived processes (like dbus-send, perhaps, in a
mode where it doesn't wait for a reply) would just skip sending it,
because the recipient can't use it in a reliable manner.

Although, TBH, it might be better to just return -1 from
GetConnectionUnixProcessID when kdbus is being used, since anything
that breaks might be breaking because it's vulnerable...

>
>>  - starttime should have a justification or be removed.
>
> I think its justification is "detect pid reuse", although AIUI it
> doesn't detect pid "reuse" via exec().

Ugh.  I really don't think the kernel should add a new feature to make
a broken, racy concept slightly less racy.  I'm fully in favor of
making it completely non-racy, but this isn't the way to do it.
(Also, anything that actually relies on this is unlikely to survive
checkpoint/restore.)

>
>>  - KDBUS_ATTACH_AUXGROUPS: I'm not sure what to think about this.  I
>> feel like it's only useful for implementing strange types of policies.
>
> I think the intention is that it enables things like "processes with
> group netdev may tell NetworkManager to reconfigure networking".
> Traditional D-Bus half-supports this, but interacts poorly with things
> like pam_groups that assign groups to processes, not uids.

That's what I guessed, too.  I'm not sure whether I like it.

>
>>  - KDBUS_ATTACH_SECLABEL: The docs talk about selinux.  What does this
>> even mean on a non-selinux system?
>
> As far as I understand it, sockets have a generic mechanism for storing
> one arbitrary security label alongside the uid, and the active LSM gets
> to define its syntax and what it means. This is the equivalent of that.

The UNIX socket credential mechanism is not a good role model, and
"something else does this too" is not a sufficient justification for
new code.  I want to make sure that someone actually understands what
this thing does and whether it's a good idea.

Unfortunately, I suspect that most or all kdbus developers either
don't use LSMs at all or use selinux, which means that may not be
anyone who has considered the big picture here.

[...]

>
>> Otherwise we'll end up with two
>> separate selinux policy databases -- the normal one and whatever dbus
>> tries to do
>
> Traditional D-Bus already has this problem: dbus-daemon has to work out
> "what would SELinux do?" in userland, including the decision whether to
> enforce or just complain, and do the same. My understanding is that one
> of the more minor upsides of doing (this part of) D-Bus in the kernel is
> that it would remove that intermediary, moving the security decisions to
> a location where LSMs can allow/deny things directly.

I absolutely agree.  It seems that the logical conclusion is that the
security label should *not* be passed to userspace, then -- once LSMs
can make decisions directly, userspace should let them make those
decisions and consider only the result of the decision, not the labels
that influenced the decision.

--Andy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Early comments on kdbus v2 (Re: [PATCH 00/12] Add kdbus implementation)

[Simon McVittie]

On 05/11/14 15:56, Andy Lutomirski wrote:
>  - I tend to think that pid and tid should be separate.  They're
> really their own thing, and, as noted in all the perfectly valid
> dislike directed at SO_PEERCRED, they have extremely limited value.

Traditional D-Bus has GetConnectionUnixProcessID(), which is used by
several applications:
,
 (the latter is the Qt
binding).

I don't know what those applications use it for, or whether they're
doing it safely. CVE-2013-4288, CVE-2014-5033 seem potentially relevant.

In the same way that kernel people don't want to break userland, I don't
want to break existing D-Bus users; it would be a shame if kdbus omits
things that would let it replace traditional D-Bus.

>  - starttime should have a justification or be removed.

I think its justification is "detect pid reuse", although AIUI it
doesn't detect pid "reuse" via exec().

>  - KDBUS_ATTACH_AUXGROUPS: I'm not sure what to think about this.  I
> feel like it's only useful for implementing strange types of policies.

I think the intention is that it enables things like "processes with
group netdev may tell NetworkManager to reconfigure networking".
Traditional D-Bus half-supports this, but interacts poorly with things
like pam_groups that assign groups to processes, not uids.

>  - KDBUS_ATTACH_SECLABEL: The docs talk about selinux.  What does this
> even mean on a non-selinux system?

As far as I understand it, sockets have a generic mechanism for storing
one arbitrary security label alongside the uid, and the active LSM gets
to define its syntax and what it means. This is the equivalent of that.

Traditional D-Bus has GetConnectionSELinuxSecurityContext() which only
returns the SELinux context, and never any other LSM's
context/label/profile/whatever.

suggests that it has users; I don't know what they do with it, or
whether they're correct.

The intention was that each LSM with code in dbus-daemon will eventually
contribute a key/value pair to GetConnectionCredentials() rather than
having their own separate methods, with
GetConnectionSELinuxSecurityContext() deprecated, but that's blocked by
people who understand the LSMs contributing the necessary code and
documentation. (Incidentally, if anyone reading this can contribute
proper documentation of the SELinux context to the D-Bus Specification -
what is the preferred jargon term? what do a couple of typical values
look like? is it restricted to some limited character set? etc. - I
would be grateful for a patch.)

Of course, if kdbus ends up being what everyone uses for D-Bus on Linux,
then there will no longer be much point in adding Linux-specific
features to dbus-daemon.

> Otherwise we'll end up with two
> separate selinux policy databases -- the normal one and whatever dbus
> tries to do

Traditional D-Bus already has this problem: dbus-daemon has to work out
"what would SELinux do?" in userland, including the decision whether to
enforce or just complain, and do the same. My understanding is that one
of the more minor upsides of doing (this part of) D-Bus in the kernel is
that it would remove that intermediary, moving the security decisions to
a location where LSMs can allow/deny things directly.

S

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Early comments on kdbus v2 (Re: [PATCH 00/12] Add kdbus implementation)

[Andy Lutomirski]

On Wed, Nov 5, 2014 at 6:34 AM, Daniel Mack  wrote:
> On 10/29/2014 11:19 PM, Andy Lutomirski wrote:
>> I think that each piece of trustable metadata needs to be explicitly
>> opted-in to by the sender at the time of capture.  Otherwise you're
>> asking for lots of information leaks and privilege escalations.  This
>> is especially important given that some of the items in the current
>> list could be rather sensitive.
>
> Alright, the above seems to pretty much sum up that end of our
> discussion. To address this, We've now added the following functionality
> for v2:
>
>  * The attach_flags in kdbus_cmd_hello was split into two parts,
>attach_flags_send and attach_flags_recv, so each peer may chose what
>exactly it want to transmit or receive.
>
>  * Metadata will only be attached to the final message in the
>receiver's pool if both the sender's attach_flags_send and the
>receiver's attach_flags_recv bit are set.
>
>  * Consequently, the existing KDBUS_ITEM_ATTACH_FLAGS item type is
>split into KDBUS_ITEM_ATTACH_FLAGS_SEND and
>KDBUS_ITEM_ATTACH_FLAGS_RECV, so that both connection details can be
>separately updated through KDBUS_CMD_CONN_UPDATE.
>
>  * To allow for use cases that require certain metadata to be attached
>on each message, we've added a negotiation mechanism to the HELLO
>ioctl: An optional metadata mask can be passed during the creation
>of buses, so bus owners may require certain bits in
>attach_flags_send to be set. That way, the creator of the bus will
>specify which metadata is required to fulfill the requirements of
>the specification of the role of the bus.
>
>

Thanks!

Here are some early thoughts based on reading what I think is the v2
documentation online.

My general impression is that the semantics of and use cases for
passing fds around (including through execve) are not well thought
out.  I think that the kdbus designers need to decide whether kdbus
fds will ever be passed between processes (via execve, SCM_RIGHTS, or
kdbus).  If yes, there are several issues:

The docs for metadata and namespaces suggest that passing fds between
namespaces turns off metadata.  I don't want to reopen this particular
discussion until Eric is back, and I don't think that the code matches
the docs, but to me this suggests that no one has really considered
how this case is supposed to behave.

I think that KDBUS_MESSAGE_SEND needs to specify metadata items to
send.  Otherwise you'll introduce security problems the first time you
ever have a process that accepts a kdbus fd from a process that it
should not fully trust.  (Note that this is not just my overly
paranoid imagination.  I've found real security bugs in netlink and
procfs based on this.  And SCM_CREDENTIALS is broken for similar
reasons.)  Also, the userspace libraries will need to be rather
careful about setting those bits.

I don't see a mechanism to prevent resource exhaustion issues in which
many fds are recursively shoved into kdbus.  (You still may need to
address this to some extent if you disallow the transfer of kdbus fds,
but it's probably easier to handle.)


If no:

KDBUS_MESSAGE_SEND should not send metadata items at all, because they
will never be interesting.



What privilege do you need to create a custom endpoint?  What
privilege do you need to set its policy?  Why do custom endpoints have
names at all?



Metadata:

Please justify each and every metadata with an actual use case or
remove it.  The justification should include an explanation of why the
same thing can't be achieved with policy.

Off the top of my head:

 - KDBUS_ATTACH_TIMESTAMP is fine.

 - KDBUS_ATTACH_CREDS should be just uid and gid

 - I tend to think that pid and tid should be separate.  They're
really their own thing, and, as noted in all the perfectly valid
dislike directed at SO_PEERCRED, they have extremely limited value.

 - starttime should have a justification or be removed.

 - KDBUS_ATTACH_AUXGROUPS: I'm not sure what to think about this.  I
feel like it's only useful for implementing strange types of policies.

 - KDBUS_ATTACH_COMM, KDBUS_ATTACH_CMDLINE, and KDBUS_ATTACH_EXE: Just
remove them.  There is no point whatsoever in having the kernel try to
validate comm and cmdline, and exe is barely better [1].  You realize
that there's this thing called PR_SET_NAME, right?  Removing these may
benefit your arguments about the whole metadata mechanism, too --
these three items are wonderful straw men to poke at, because any
concept of trusting them is absurd even ignoring the framework in
which they're used.  But you can't tell people to shut up and stop
attacking straw men, because you've actually proposed these particular
straw men. :)

 - KDBUS_ATTACH_CGROUP: This sounds legitimately useful.

 - KDBUS_ATTACH_SECLABEL: The docs talk about selinux.  What does this
even mean on a non-selinux system?  I tend to think that this
shouldn't exist as a metadata item and that all selinux integration

Re: [PATCH 00/12] Add kdbus implementation

[Daniel Mack]

On 10/29/2014 11:19 PM, Andy Lutomirski wrote:
> I think that each piece of trustable metadata needs to be explicitly
> opted-in to by the sender at the time of capture.  Otherwise you're
> asking for lots of information leaks and privilege escalations.  This
> is especially important given that some of the items in the current
> list could be rather sensitive.

Alright, the above seems to pretty much sum up that end of our
discussion. To address this, We've now added the following functionality
for v2:

 * The attach_flags in kdbus_cmd_hello was split into two parts,
   attach_flags_send and attach_flags_recv, so each peer may chose what
   exactly it want to transmit or receive.

 * Metadata will only be attached to the final message in the
   receiver's pool if both the sender's attach_flags_send and the
   receiver's attach_flags_recv bit are set.

 * Consequently, the existing KDBUS_ITEM_ATTACH_FLAGS item type is
   split into KDBUS_ITEM_ATTACH_FLAGS_SEND and
   KDBUS_ITEM_ATTACH_FLAGS_RECV, so that both connection details can be
   separately updated through KDBUS_CMD_CONN_UPDATE.

 * To allow for use cases that require certain metadata to be attached
   on each message, we've added a negotiation mechanism to the HELLO
   ioctl: An optional metadata mask can be passed during the creation
   of buses, so bus owners may require certain bits in
   attach_flags_send to be set. That way, the creator of the bus will
   specify which metadata is required to fulfill the requirements of
   the specification of the role of the bus.


Thanks again for your input!

Daniel
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 00/12] Add kdbus implementation

[Daniel Mack]

On 10/29/2014 11:19 PM, Andy Lutomirski wrote:
 I think that each piece of trustable metadata needs to be explicitly
 opted-in to by the sender at the time of capture.  Otherwise you're
 asking for lots of information leaks and privilege escalations.  This
 is especially important given that some of the items in the current
 list could be rather sensitive.

Alright, the above seems to pretty much sum up that end of our
discussion. To address this, We've now added the following functionality
for v2:

 * The attach_flags in kdbus_cmd_hello was split into two parts,
   attach_flags_send and attach_flags_recv, so each peer may chose what
   exactly it want to transmit or receive.

 * Metadata will only be attached to the final message in the
   receiver's pool if both the sender's attach_flags_send and the
   receiver's attach_flags_recv bit are set.

 * Consequently, the existing KDBUS_ITEM_ATTACH_FLAGS item type is
   split into KDBUS_ITEM_ATTACH_FLAGS_SEND and
   KDBUS_ITEM_ATTACH_FLAGS_RECV, so that both connection details can be
   separately updated through KDBUS_CMD_CONN_UPDATE.

 * To allow for use cases that require certain metadata to be attached
   on each message, we've added a negotiation mechanism to the HELLO
   ioctl: An optional metadata mask can be passed during the creation
   of buses, so bus owners may require certain bits in
   attach_flags_send to be set. That way, the creator of the bus will
   specify which metadata is required to fulfill the requirements of
   the specification of the role of the bus.


Thanks again for your input!

Daniel
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Early comments on kdbus v2 (Re: [PATCH 00/12] Add kdbus implementation)

[Andy Lutomirski]

On Wed, Nov 5, 2014 at 6:34 AM, Daniel Mack dan...@zonque.org wrote:
 On 10/29/2014 11:19 PM, Andy Lutomirski wrote:
 I think that each piece of trustable metadata needs to be explicitly
 opted-in to by the sender at the time of capture.  Otherwise you're
 asking for lots of information leaks and privilege escalations.  This
 is especially important given that some of the items in the current
 list could be rather sensitive.

 Alright, the above seems to pretty much sum up that end of our
 discussion. To address this, We've now added the following functionality
 for v2:

  * The attach_flags in kdbus_cmd_hello was split into two parts,
attach_flags_send and attach_flags_recv, so each peer may chose what
exactly it want to transmit or receive.

  * Metadata will only be attached to the final message in the
receiver's pool if both the sender's attach_flags_send and the
receiver's attach_flags_recv bit are set.

  * Consequently, the existing KDBUS_ITEM_ATTACH_FLAGS item type is
split into KDBUS_ITEM_ATTACH_FLAGS_SEND and
KDBUS_ITEM_ATTACH_FLAGS_RECV, so that both connection details can be
separately updated through KDBUS_CMD_CONN_UPDATE.

  * To allow for use cases that require certain metadata to be attached
on each message, we've added a negotiation mechanism to the HELLO
ioctl: An optional metadata mask can be passed during the creation
of buses, so bus owners may require certain bits in
attach_flags_send to be set. That way, the creator of the bus will
specify which metadata is required to fulfill the requirements of
the specification of the role of the bus.



Thanks!

Here are some early thoughts based on reading what I think is the v2
documentation online.

My general impression is that the semantics of and use cases for
passing fds around (including through execve) are not well thought
out.  I think that the kdbus designers need to decide whether kdbus
fds will ever be passed between processes (via execve, SCM_RIGHTS, or
kdbus).  If yes, there are several issues:

The docs for metadata and namespaces suggest that passing fds between
namespaces turns off metadata.  I don't want to reopen this particular
discussion until Eric is back, and I don't think that the code matches
the docs, but to me this suggests that no one has really considered
how this case is supposed to behave.

I think that KDBUS_MESSAGE_SEND needs to specify metadata items to
send.  Otherwise you'll introduce security problems the first time you
ever have a process that accepts a kdbus fd from a process that it
should not fully trust.  (Note that this is not just my overly
paranoid imagination.  I've found real security bugs in netlink and
procfs based on this.  And SCM_CREDENTIALS is broken for similar
reasons.)  Also, the userspace libraries will need to be rather
careful about setting those bits.

I don't see a mechanism to prevent resource exhaustion issues in which
many fds are recursively shoved into kdbus.  (You still may need to
address this to some extent if you disallow the transfer of kdbus fds,
but it's probably easier to handle.)


If no:

KDBUS_MESSAGE_SEND should not send metadata items at all, because they
will never be interesting.



What privilege do you need to create a custom endpoint?  What
privilege do you need to set its policy?  Why do custom endpoints have
names at all?



Metadata:

Please justify each and every metadata with an actual use case or
remove it.  The justification should include an explanation of why the
same thing can't be achieved with policy.

Off the top of my head:

 - KDBUS_ATTACH_TIMESTAMP is fine.

 - KDBUS_ATTACH_CREDS should be just uid and gid

 - I tend to think that pid and tid should be separate.  They're
really their own thing, and, as noted in all the perfectly valid
dislike directed at SO_PEERCRED, they have extremely limited value.

 - starttime should have a justification or be removed.

 - KDBUS_ATTACH_AUXGROUPS: I'm not sure what to think about this.  I
feel like it's only useful for implementing strange types of policies.

 - KDBUS_ATTACH_COMM, KDBUS_ATTACH_CMDLINE, and KDBUS_ATTACH_EXE: Just
remove them.  There is no point whatsoever in having the kernel try to
validate comm and cmdline, and exe is barely better [1].  You realize
that there's this thing called PR_SET_NAME, right?  Removing these may
benefit your arguments about the whole metadata mechanism, too --
these three items are wonderful straw men to poke at, because any
concept of trusting them is absurd even ignoring the framework in
which they're used.  But you can't tell people to shut up and stop
attacking straw men, because you've actually proposed these particular
straw men. :)

 - KDBUS_ATTACH_CGROUP: This sounds legitimately useful.

 - KDBUS_ATTACH_SECLABEL: The docs talk about selinux.  What does this
even mean on a non-selinux system?  I tend to think that this
shouldn't exist as a metadata item and that all selinux integration
should go through the 

Re: Early comments on kdbus v2 (Re: [PATCH 00/12] Add kdbus implementation)

[Simon McVittie]

On 05/11/14 15:56, Andy Lutomirski wrote:
  - I tend to think that pid and tid should be separate.  They're
 really their own thing, and, as noted in all the perfectly valid
 dislike directed at SO_PEERCRED, they have extremely limited value.

Traditional D-Bus has GetConnectionUnixProcessID(), which is used by
several applications:
http://codesearch.debian.net/search?q=GetConnectionUnixProcessID,
http://codesearch.debian.net/search?q=servicePid (the latter is the Qt
binding).

I don't know what those applications use it for, or whether they're
doing it safely. CVE-2013-4288, CVE-2014-5033 seem potentially relevant.

In the same way that kernel people don't want to break userland, I don't
want to break existing D-Bus users; it would be a shame if kdbus omits
things that would let it replace traditional D-Bus.

  - starttime should have a justification or be removed.

I think its justification is detect pid reuse, although AIUI it
doesn't detect pid reuse via exec().

  - KDBUS_ATTACH_AUXGROUPS: I'm not sure what to think about this.  I
 feel like it's only useful for implementing strange types of policies.

I think the intention is that it enables things like processes with
group netdev may tell NetworkManager to reconfigure networking.
Traditional D-Bus half-supports this, but interacts poorly with things
like pam_groups that assign groups to processes, not uids.

  - KDBUS_ATTACH_SECLABEL: The docs talk about selinux.  What does this
 even mean on a non-selinux system?

As far as I understand it, sockets have a generic mechanism for storing
one arbitrary security label alongside the uid, and the active LSM gets
to define its syntax and what it means. This is the equivalent of that.

Traditional D-Bus has GetConnectionSELinuxSecurityContext() which only
returns the SELinux context, and never any other LSM's
context/label/profile/whatever.
http://codesearch.debian.net/search?q=GetConnectionSELinuxSecurityContext
suggests that it has users; I don't know what they do with it, or
whether they're correct.

The intention was that each LSM with code in dbus-daemon will eventually
contribute a key/value pair to GetConnectionCredentials() rather than
having their own separate methods, with
GetConnectionSELinuxSecurityContext() deprecated, but that's blocked by
people who understand the LSMs contributing the necessary code and
documentation. (Incidentally, if anyone reading this can contribute
proper documentation of the SELinux context to the D-Bus Specification -
what is the preferred jargon term? what do a couple of typical values
look like? is it restricted to some limited character set? etc. - I
would be grateful for a patch.)

Of course, if kdbus ends up being what everyone uses for D-Bus on Linux,
then there will no longer be much point in adding Linux-specific
features to dbus-daemon.

 Otherwise we'll end up with two
 separate selinux policy databases -- the normal one and whatever dbus
 tries to do

Traditional D-Bus already has this problem: dbus-daemon has to work out
what would SELinux do? in userland, including the decision whether to
enforce or just complain, and do the same. My understanding is that one
of the more minor upsides of doing (this part of) D-Bus in the kernel is
that it would remove that intermediary, moving the security decisions to
a location where LSMs can allow/deny things directly.

S

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Early comments on kdbus v2 (Re: [PATCH 00/12] Add kdbus implementation)

[Andy Lutomirski]

On Wed, Nov 5, 2014 at 9:02 AM, Simon McVittie
simon.mcvit...@collabora.co.uk wrote:
 On 05/11/14 15:56, Andy Lutomirski wrote:
  - I tend to think that pid and tid should be separate.  They're
 really their own thing, and, as noted in all the perfectly valid
 dislike directed at SO_PEERCRED, they have extremely limited value.

 Traditional D-Bus has GetConnectionUnixProcessID(), which is used by
 several applications:
 http://codesearch.debian.net/search?q=GetConnectionUnixProcessID,
 http://codesearch.debian.net/search?q=servicePid (the latter is the Qt
 binding).

 I don't know what those applications use it for, or whether they're
 doing it safely. CVE-2013-4288, CVE-2014-5033 seem potentially relevant.

 In the same way that kernel people don't want to break userland, I don't
 want to break existing D-Bus users; it would be a shame if kdbus omits
 things that would let it replace traditional D-Bus.

That's why I suggested separating it, not removing it.  If it were
separate, then short-lived processes (like dbus-send, perhaps, in a
mode where it doesn't wait for a reply) would just skip sending it,
because the recipient can't use it in a reliable manner.

Although, TBH, it might be better to just return -1 from
GetConnectionUnixProcessID when kdbus is being used, since anything
that breaks might be breaking because it's vulnerable...


  - starttime should have a justification or be removed.

 I think its justification is detect pid reuse, although AIUI it
 doesn't detect pid reuse via exec().

Ugh.  I really don't think the kernel should add a new feature to make
a broken, racy concept slightly less racy.  I'm fully in favor of
making it completely non-racy, but this isn't the way to do it.
(Also, anything that actually relies on this is unlikely to survive
checkpoint/restore.)


  - KDBUS_ATTACH_AUXGROUPS: I'm not sure what to think about this.  I
 feel like it's only useful for implementing strange types of policies.

 I think the intention is that it enables things like processes with
 group netdev may tell NetworkManager to reconfigure networking.
 Traditional D-Bus half-supports this, but interacts poorly with things
 like pam_groups that assign groups to processes, not uids.

That's what I guessed, too.  I'm not sure whether I like it.


  - KDBUS_ATTACH_SECLABEL: The docs talk about selinux.  What does this
 even mean on a non-selinux system?

 As far as I understand it, sockets have a generic mechanism for storing
 one arbitrary security label alongside the uid, and the active LSM gets
 to define its syntax and what it means. This is the equivalent of that.

The UNIX socket credential mechanism is not a good role model, and
something else does this too is not a sufficient justification for
new code.  I want to make sure that someone actually understands what
this thing does and whether it's a good idea.

Unfortunately, I suspect that most or all kdbus developers either
don't use LSMs at all or use selinux, which means that may not be
anyone who has considered the big picture here.

[...]


 Otherwise we'll end up with two
 separate selinux policy databases -- the normal one and whatever dbus
 tries to do

 Traditional D-Bus already has this problem: dbus-daemon has to work out
 what would SELinux do? in userland, including the decision whether to
 enforce or just complain, and do the same. My understanding is that one
 of the more minor upsides of doing (this part of) D-Bus in the kernel is
 that it would remove that intermediary, moving the security decisions to
 a location where LSMs can allow/deny things directly.

I absolutely agree.  It seems that the logical conclusion is that the
security label should *not* be passed to userspace, then -- once LSMs
can make decisions directly, userspace should let them make those
decisions and consider only the result of the decision, not the labels
that influenced the decision.

--Andy
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 00/12] Add kdbus implementation

[One Thousand Gnomes]

On Sat, 1 Nov 2014 18:21:30 -0700
Greg Kroah-Hartman  wrote:

> Here's some reasons why I feel it is better to have kdbus in the kernel
> rather than trying to implement the same thing in a userspace daemon:

No - these are reasons to have *something* in the kernel. I think it
would be far more constructive to treat the current kdbus as a proof of
concept/prototype or even a draft requirements specification.

>   as the only trustworthy compoenent in the game is the kernel which
>   adds metadata and ensures that all data passed as payload is either
>   copied or sealed, so that the receiver can parse the data without

When the kernel adds metadata without being told to do so by one end of
the link you create a new set of security and privacy leaks. Far better
that the sender must choose what metadata is added and the receiver can
decide to bin stuff that's not acceptable. The job of the kernel is
really more like that of an auditor in a business transaction - to make
sure that the data they agree to pass is truthful.

(ie its the sender who must say "attach my user info", the receiver who
must say "no info, no play" and the kernel who must provide the info so
it can't be faked.

> - semantics for apps with heavy data payloads (media apps, for instance)
>   with optinal priority message dequeuing, and global message ordering.

Sounds like System 5 IPC ;-)

> Regarding binder: binder and kdbus follow very different design
> concepts. 

We know binder is broken but the Android guys are stuck in a special
kind of hell with it for some years to come. We need to make sure kdbus
isn't the same result.

Alan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 00/12] Add kdbus implementation

[One Thousand Gnomes]

On Sat, 1 Nov 2014 18:21:30 -0700
Greg Kroah-Hartman gre...@linuxfoundation.org wrote:

 Here's some reasons why I feel it is better to have kdbus in the kernel
 rather than trying to implement the same thing in a userspace daemon:

No - these are reasons to have *something* in the kernel. I think it
would be far more constructive to treat the current kdbus as a proof of
concept/prototype or even a draft requirements specification.

   as the only trustworthy compoenent in the game is the kernel which
   adds metadata and ensures that all data passed as payload is either
   copied or sealed, so that the receiver can parse the data without

When the kernel adds metadata without being told to do so by one end of
the link you create a new set of security and privacy leaks. Far better
that the sender must choose what metadata is added and the receiver can
decide to bin stuff that's not acceptable. The job of the kernel is
really more like that of an auditor in a business transaction - to make
sure that the data they agree to pass is truthful.

(ie its the sender who must say attach my user info, the receiver who
must say no info, no play and the kernel who must provide the info so
it can't be faked.

 - semantics for apps with heavy data payloads (media apps, for instance)
   with optinal priority message dequeuing, and global message ordering.

Sounds like System 5 IPC ;-)

 Regarding binder: binder and kdbus follow very different design
 concepts. 

We know binder is broken but the Android guys are stuck in a special
kind of hell with it for some years to come. We need to make sure kdbus
isn't the same result.

Alan
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 00/12] Add kdbus implementation

[Greg Kroah-Hartman]

On Thu, Oct 30, 2014 at 12:00:16AM +0100, Jiri Kosina wrote:
> On Wed, 29 Oct 2014, Greg Kroah-Hartman wrote:
> 
> > kdbus is a kernel-level IPC implementation that aims for resemblance to
> > the the protocol layer with the existing userspace D-Bus daemon while
> > enabling some features that couldn't be implemented before in userspace.
> 
> I'd be interested in the features that can't be implemented in userspace 
> (and therefore would justify existence of kdbus in the kernel). Could you 
> please point me to such list / documentation?
> 
> It seems to me that most of the highlight features from the cover letter 
> can be "easily" (for certain definition of that word, of course) 
> implemented in userspace (vmsplice(), sending fd through unix socket, user 
> namespaces, UUID management, etc).

Sorry for the long delay in getting back to this, I'm battling a bad
case of jet-lag at the moment...

Here's some reasons why I feel it is better to have kdbus in the kernel
rather than trying to implement the same thing in a userspace daemon:

- performance: fewer process context switches, fewer copies, fewer
  syscalls, larger memory chunks via memfd.  This is really important
  for a whole class of userspace programs that are ported from other
  operating systems that are run on tiny ARM systems that rely on
  hundreds of thousands of messages passed at boot time, and at
  "critical" times in their user interaction loops.
- security: the peers which communicate do not have to trust each other,
  as the only trustworthy compoenent in the game is the kernel which
  adds metadata and ensures that all data passed as payload is either
  copied or sealed, so that the receiver can parse the data without
  having to protect against changing memory while parsing buffers.  Also,
  all the data transfer is controlled by the kernel, so that LSMs can
  track and control what is going on, without involving userspace.
  Because of the LSM issue, security people are much happier with this
  model than the current scheme of having to hook into dbus to mediate
  things.
- more metadata can be attached to messages than in userspace
- semantics for apps with heavy data payloads (media apps, for instance)
  with optinal priority message dequeuing, and global message ordering.
  Some "crazy" people are playing with using kdbus for audio data in the
  system.  I'm not saying that this is the best model for this, but
  until now, there wasn't any other way to do this without having to
  create custom "busses", one for each application library.
- being in the kernle closes a lot of races which can't be fixed with
  the current userspace solutions.  For example, with kdbus, there is a
  way a client can disconnect from a bus, but do so only if no further
  messages present in its queue, which is crucial for implementing
  race-free "exit-on-idle" services
- eavesdropping on the kernel level, so privileged users can hook into
  the message stream without hacking support for that into their
  userspace processes
- a number of smaller benefits: for example kdbus learned a way to peek
  full messages without dequeing them, which is really useful for
  logging metadata when handling bus-activation requests. 

Of course, some of the bits above could be implemented in userspace
alone, for example with more sophisticated memory management APIs, but
this is usually done by losing out on the other details.  For example,
for many of the memory management APIs, it's hard to not require the
communicating peers to fully trust each other.  And we _really_ don't
want peers to have to trust each other.

Another benefit of having this in the kernel, rather than as a userspace
daemon, is that you can now easily use the bus from the initrd, or up to
the very end when the system shuts down.  On current userspace D-Bus,
this is not really possible, as this requires passing the bus instance
around between initrd and the "real" system.  Such a transition of all
fds also requires keeping full state of what has already been read from
the connection fds.  kdbus makes this much simpler, as we can change the
ownership of the bus, just by passing one fd over from one part to the
other.

Regarding binder: binder and kdbus follow very different design
concepts.  Binder implies the use of thread-pools to dispatch incoming
method calls.  This is a very efficient scheme, and completely natural
in programming languages like Java.  On most Linux programs, however,
there's a much stronger focus on central poll() loops that dispatch all
sources a program cares about.  kdbus is much more usable in such
environments, as it doesn't enforce a threading model, and it is happy
with serialized dispatching.  In fact, this major difference had an
effect on much of the design decisions: binder does not guarantee global
message ordering due to the parallel dispatching in the thread-pools,
but  kdbus does.  Moreover, there's also a difference in the way message
handling.  In kdbus, 

Re: [PATCH 00/12] Add kdbus implementation

[Greg Kroah-Hartman]

On Thu, Oct 30, 2014 at 12:00:16AM +0100, Jiri Kosina wrote:
 On Wed, 29 Oct 2014, Greg Kroah-Hartman wrote:
 
  kdbus is a kernel-level IPC implementation that aims for resemblance to
  the the protocol layer with the existing userspace D-Bus daemon while
  enabling some features that couldn't be implemented before in userspace.
 
 I'd be interested in the features that can't be implemented in userspace 
 (and therefore would justify existence of kdbus in the kernel). Could you 
 please point me to such list / documentation?
 
 It seems to me that most of the highlight features from the cover letter 
 can be easily (for certain definition of that word, of course) 
 implemented in userspace (vmsplice(), sending fd through unix socket, user 
 namespaces, UUID management, etc).

Sorry for the long delay in getting back to this, I'm battling a bad
case of jet-lag at the moment...

Here's some reasons why I feel it is better to have kdbus in the kernel
rather than trying to implement the same thing in a userspace daemon:

- performance: fewer process context switches, fewer copies, fewer
  syscalls, larger memory chunks via memfd.  This is really important
  for a whole class of userspace programs that are ported from other
  operating systems that are run on tiny ARM systems that rely on
  hundreds of thousands of messages passed at boot time, and at
  critical times in their user interaction loops.
- security: the peers which communicate do not have to trust each other,
  as the only trustworthy compoenent in the game is the kernel which
  adds metadata and ensures that all data passed as payload is either
  copied or sealed, so that the receiver can parse the data without
  having to protect against changing memory while parsing buffers.  Also,
  all the data transfer is controlled by the kernel, so that LSMs can
  track and control what is going on, without involving userspace.
  Because of the LSM issue, security people are much happier with this
  model than the current scheme of having to hook into dbus to mediate
  things.
- more metadata can be attached to messages than in userspace
- semantics for apps with heavy data payloads (media apps, for instance)
  with optinal priority message dequeuing, and global message ordering.
  Some crazy people are playing with using kdbus for audio data in the
  system.  I'm not saying that this is the best model for this, but
  until now, there wasn't any other way to do this without having to
  create custom busses, one for each application library.
- being in the kernle closes a lot of races which can't be fixed with
  the current userspace solutions.  For example, with kdbus, there is a
  way a client can disconnect from a bus, but do so only if no further
  messages present in its queue, which is crucial for implementing
  race-free exit-on-idle services
- eavesdropping on the kernel level, so privileged users can hook into
  the message stream without hacking support for that into their
  userspace processes
- a number of smaller benefits: for example kdbus learned a way to peek
  full messages without dequeing them, which is really useful for
  logging metadata when handling bus-activation requests. 

Of course, some of the bits above could be implemented in userspace
alone, for example with more sophisticated memory management APIs, but
this is usually done by losing out on the other details.  For example,
for many of the memory management APIs, it's hard to not require the
communicating peers to fully trust each other.  And we _really_ don't
want peers to have to trust each other.

Another benefit of having this in the kernel, rather than as a userspace
daemon, is that you can now easily use the bus from the initrd, or up to
the very end when the system shuts down.  On current userspace D-Bus,
this is not really possible, as this requires passing the bus instance
around between initrd and the real system.  Such a transition of all
fds also requires keeping full state of what has already been read from
the connection fds.  kdbus makes this much simpler, as we can change the
ownership of the bus, just by passing one fd over from one part to the
other.

Regarding binder: binder and kdbus follow very different design
concepts.  Binder implies the use of thread-pools to dispatch incoming
method calls.  This is a very efficient scheme, and completely natural
in programming languages like Java.  On most Linux programs, however,
there's a much stronger focus on central poll() loops that dispatch all
sources a program cares about.  kdbus is much more usable in such
environments, as it doesn't enforce a threading model, and it is happy
with serialized dispatching.  In fact, this major difference had an
effect on much of the design decisions: binder does not guarantee global
message ordering due to the parallel dispatching in the thread-pools,
but  kdbus does.  Moreover, there's also a difference in the way message
handling.  In kdbus, every message is basically taken 

Re: [PATCH 00/12] Add kdbus implementation

[Karol Lewandowski]

On 2014-10-31 00:39, Paul Moore wrote:
> On Thursday, October 30, 2014 08:55:56 PM Karol Lewandowski wrote:
>> On 2014-10-30 15:47, Greg Kroah-Hartman wrote:
>>> Other than that, I don't know exactly what your patches do, or why they
>>> are needed, care to go into details?
>>
>> Patches in question were supposed to add few hooks for kdbus-specific
>> operations that doesn't seem to have compatible semantics with hooks
>> currently available in LSM.
>>
>> kdbus' bus introduces quite a few new concepts that we wanted to be able
>> to limit based on MAC label/context, eg.
>>
>>  - check flags at HELO stage (say disallow fd passing),
>>
>>  - restrict ability to acquire name to certain subjects (for system bus),
>>
>>  - disallow creation of new buses,
>>
>>  - limit scope of broadcasts,
>>
>>  - etc.
>>
>> Please take a look at hook list - I think most of names are
>> self-explanatory:
>>
>>  
>> https://github.com/lmctl/linux/blob/a9fe4c33b6e5ab25a243e0590df406aabb6add1
>> 2/include/linux/security.h#L1874
>>
>> kdbus modifications were pretty light - with most visible change being
>> addition of opaque security pointer to kdbus_bus and similar structs.
> 
> [NOTE: we really should add the LSM list to this discussion and future 
> patchset postings.]
> 
> Also, to be completely honest, I don't think we ever really arrived at any 
> final conclusion about those LSM/kdbus hooks either.  At least I don't think 
> I 
> ever really satisfied myself that what we had was the "right" solution.

Agreed, "hooks" are far from being complete.  I think that patches
were and still are - a starting point for discussion, not "a solution"
itself.

Timing wasn't good either - since our last discussion (Apr/May 2014)
kdbus policy engine has been completely rewritten and few core concepts
changed too.

> We both got busy and kinda drifted away from this effort.  Karol, did you do 
> any further work on the hooks?

I didn't.  I was waiting for the peace of change in kdbus to slow
down a bit and, honestly, wasn't expecting submission in few next
months...

I'll do my best to post RFC patchset today or tomorrow.

Thanks
-- 
Karol Lewandowski, Samsung R Institute Poland
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 00/12] Add kdbus implementation

[Karol Lewandowski]

On 2014-10-30 21:24, Greg Kroah-Hartman wrote:
> On Thu, Oct 30, 2014 at 08:55:56PM +0100, Karol Lewandowski wrote:
>> On 2014-10-30 15:47, Greg Kroah-Hartman wrote:
>>> On Thu, Oct 30, 2014 at 11:44:39AM +0100, Karol Lewandowski wrote:
 [ Sorry for breaking thread and resend - gmane rejected my original message
   due to too long list of recipients... ]

 On 2014-10-30 00:40, Greg Kroah-Hartman wrote:

> There is a 1815 line documentation file in this series, so we aren't
> trying to not provide this type of information here at all.  But yes,
> more background, about why this can't be done in userspace (zero copy,
> less context switches, proper credential passing, timestamping, availble
> at early-boot, LSM hooks for security models to tie into

 While you're at it... I did some work on proof-of-concept LSM patches for
 kdbus some time ago, see [1][2].  Currently, these are completely of date.

  [1] https://github.com/lmctl/linux/commits/kdbus-lsm-v4.for-systemd-v212
  [2] 
 https://github.com/lmctl/kdbus/commit/aa0885489d19be92fa41c6f0a71df28763228a40

 May I ask if you guys have your own plan for LSM or maybe it would be
 worth to resurrect [1]?
>>>
>>> The core calls are already mediated by LSM today, right?  We don't want
>>> anyone to be parsing the data stream through an LSM, that idea got
>>> rejected a long time ago as something that is really not a good idea.
>>
>> Parsing data is out of question, of course, but this is not what we were
>> proposing.
> 
> Glad to hear it :)
> 
>>> Other than that, I don't know exactly what your patches do, or why they
>>> are needed, care to go into details?
>>
>> Patches in question were supposed to add few hooks for kdbus-specific
>> operations that doesn't seem to have compatible semantics with hooks
>> currently available in LSM.
>>
>> kdbus' bus introduces quite a few new concepts that we wanted to be able
>> to limit based on MAC label/context, eg.
>>
>>  - check flags at HELO stage (say disallow fd passing),
>>
>>  - restrict ability to acquire name to certain subjects (for system bus),
>>
>>  - disallow creation of new buses,
>>
>>  - limit scope of broadcasts,
>>
>>  - etc.
> 
> Nice list.
> 
>> Please take a look at hook list - I think most of names are self-explanatory:
>>
>>   
>> https://github.com/lmctl/linux/blob/a9fe4c33b6e5ab25a243e0590df406aabb6add12/include/linux/security.h#L1874
>>
>> kdbus modifications were pretty light - with most visible change being
>> addition of opaque security pointer to kdbus_bus and similar structs.
> 
> That looks very reasonable, care to make it up into a patch I can add to
> the end of this series so it's easy to review and possibly submit as
> part of it?

I'll do my best to prepare something suitable for review, but I'm
not sure it can/should be part of next patch set.

As Paul wrote - discussion about hooks hasn't really ended up with
satisfactory conclusion but just faded away.  kdbus own policy engine
has been  rewritten since I last touched it so I'm not sure what part
are still applicable.

(Unfortunately, I'll be traveling from monday and likely to be offline
for a week or two...)

Thanks
-- 
Karol Lewandowski, Samsung R Institute Poland
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 00/12] Add kdbus implementation

[Karol Lewandowski]

On 2014-10-31 00:13, One Thousand Gnomes wrote:
>>> The core calls are already mediated by LSM today, right?  We don't want
>>> anyone to be parsing the data stream through an LSM, that idea got
>>> rejected a long time ago as something that is really not a good idea.
>>
>> Parsing data is out of question, of course, but this is not what we were
>> proposing.
> 
> Why is it out of the question. If it's a socket you can just a BPF filter
> on it, so why can't kdbus support similar basic functionality ?

Fair point.  I think that none of us simply considered this till now.

Thanks
-- 
Karol Lewandowski, Samsung R Institute Poland
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 00/12] Add kdbus implementation

[Karol Lewandowski]

On 2014-10-31 00:13, One Thousand Gnomes wrote:
 The core calls are already mediated by LSM today, right?  We don't want
 anyone to be parsing the data stream through an LSM, that idea got
 rejected a long time ago as something that is really not a good idea.

 Parsing data is out of question, of course, but this is not what we were
 proposing.
 
 Why is it out of the question. If it's a socket you can just a BPF filter
 on it, so why can't kdbus support similar basic functionality ?

Fair point.  I think that none of us simply considered this till now.

Thanks
-- 
Karol Lewandowski, Samsung RD Institute Poland
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 00/12] Add kdbus implementation

[Karol Lewandowski]

On 2014-10-30 21:24, Greg Kroah-Hartman wrote:
 On Thu, Oct 30, 2014 at 08:55:56PM +0100, Karol Lewandowski wrote:
 On 2014-10-30 15:47, Greg Kroah-Hartman wrote:
 On Thu, Oct 30, 2014 at 11:44:39AM +0100, Karol Lewandowski wrote:
 [ Sorry for breaking thread and resend - gmane rejected my original message
   due to too long list of recipients... ]

 On 2014-10-30 00:40, Greg Kroah-Hartman wrote:

 There is a 1815 line documentation file in this series, so we aren't
 trying to not provide this type of information here at all.  But yes,
 more background, about why this can't be done in userspace (zero copy,
 less context switches, proper credential passing, timestamping, availble
 at early-boot, LSM hooks for security models to tie into

 While you're at it... I did some work on proof-of-concept LSM patches for
 kdbus some time ago, see [1][2].  Currently, these are completely of date.

  [1] https://github.com/lmctl/linux/commits/kdbus-lsm-v4.for-systemd-v212
  [2] 
 https://github.com/lmctl/kdbus/commit/aa0885489d19be92fa41c6f0a71df28763228a40

 May I ask if you guys have your own plan for LSM or maybe it would be
 worth to resurrect [1]?

 The core calls are already mediated by LSM today, right?  We don't want
 anyone to be parsing the data stream through an LSM, that idea got
 rejected a long time ago as something that is really not a good idea.

 Parsing data is out of question, of course, but this is not what we were
 proposing.
 
 Glad to hear it :)
 
 Other than that, I don't know exactly what your patches do, or why they
 are needed, care to go into details?

 Patches in question were supposed to add few hooks for kdbus-specific
 operations that doesn't seem to have compatible semantics with hooks
 currently available in LSM.

 kdbus' bus introduces quite a few new concepts that we wanted to be able
 to limit based on MAC label/context, eg.

  - check flags at HELO stage (say disallow fd passing),

  - restrict ability to acquire name to certain subjects (for system bus),

  - disallow creation of new buses,

  - limit scope of broadcasts,

  - etc.
 
 Nice list.
 
 Please take a look at hook list - I think most of names are self-explanatory:

   
 https://github.com/lmctl/linux/blob/a9fe4c33b6e5ab25a243e0590df406aabb6add12/include/linux/security.h#L1874

 kdbus modifications were pretty light - with most visible change being
 addition of opaque security pointer to kdbus_bus and similar structs.
 
 That looks very reasonable, care to make it up into a patch I can add to
 the end of this series so it's easy to review and possibly submit as
 part of it?

I'll do my best to prepare something suitable for review, but I'm
not sure it can/should be part of next patch set.

As Paul wrote - discussion about hooks hasn't really ended up with
satisfactory conclusion but just faded away.  kdbus own policy engine
has been  rewritten since I last touched it so I'm not sure what part
are still applicable.

(Unfortunately, I'll be traveling from monday and likely to be offline
for a week or two...)

Thanks
-- 
Karol Lewandowski, Samsung RD Institute Poland
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 00/12] Add kdbus implementation

[Karol Lewandowski]

On 2014-10-31 00:39, Paul Moore wrote:
 On Thursday, October 30, 2014 08:55:56 PM Karol Lewandowski wrote:
 On 2014-10-30 15:47, Greg Kroah-Hartman wrote:
 Other than that, I don't know exactly what your patches do, or why they
 are needed, care to go into details?

 Patches in question were supposed to add few hooks for kdbus-specific
 operations that doesn't seem to have compatible semantics with hooks
 currently available in LSM.

 kdbus' bus introduces quite a few new concepts that we wanted to be able
 to limit based on MAC label/context, eg.

  - check flags at HELO stage (say disallow fd passing),

  - restrict ability to acquire name to certain subjects (for system bus),

  - disallow creation of new buses,

  - limit scope of broadcasts,

  - etc.

 Please take a look at hook list - I think most of names are
 self-explanatory:

  
 https://github.com/lmctl/linux/blob/a9fe4c33b6e5ab25a243e0590df406aabb6add1
 2/include/linux/security.h#L1874

 kdbus modifications were pretty light - with most visible change being
 addition of opaque security pointer to kdbus_bus and similar structs.
 
 [NOTE: we really should add the LSM list to this discussion and future 
 patchset postings.]
 
 Also, to be completely honest, I don't think we ever really arrived at any 
 final conclusion about those LSM/kdbus hooks either.  At least I don't think 
 I 
 ever really satisfied myself that what we had was the right solution.

Agreed, hooks are far from being complete.  I think that patches
were and still are - a starting point for discussion, not a solution
itself.

Timing wasn't good either - since our last discussion (Apr/May 2014)
kdbus policy engine has been completely rewritten and few core concepts
changed too.

 We both got busy and kinda drifted away from this effort.  Karol, did you do 
 any further work on the hooks?

I didn't.  I was waiting for the peace of change in kdbus to slow
down a bit and, honestly, wasn't expecting submission in few next
months...

I'll do my best to post RFC patchset today or tomorrow.

Thanks
-- 
Karol Lewandowski, Samsung RD Institute Poland
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 00/12] Add kdbus implementation

[Paul Moore]

On Thursday, October 30, 2014 08:55:56 PM Karol Lewandowski wrote:
> On 2014-10-30 15:47, Greg Kroah-Hartman wrote:
> > Other than that, I don't know exactly what your patches do, or why they
> > are needed, care to go into details?
> 
> Patches in question were supposed to add few hooks for kdbus-specific
> operations that doesn't seem to have compatible semantics with hooks
> currently available in LSM.
> 
> kdbus' bus introduces quite a few new concepts that we wanted to be able
> to limit based on MAC label/context, eg.
> 
>  - check flags at HELO stage (say disallow fd passing),
> 
>  - restrict ability to acquire name to certain subjects (for system bus),
> 
>  - disallow creation of new buses,
> 
>  - limit scope of broadcasts,
> 
>  - etc.
> 
> Please take a look at hook list - I think most of names are
> self-explanatory:
> 
>  
> https://github.com/lmctl/linux/blob/a9fe4c33b6e5ab25a243e0590df406aabb6add1
> 2/include/linux/security.h#L1874
> 
> kdbus modifications were pretty light - with most visible change being
> addition of opaque security pointer to kdbus_bus and similar structs.

[NOTE: we really should add the LSM list to this discussion and future 
patchset postings.]

Also, to be completely honest, I don't think we ever really arrived at any 
final conclusion about those LSM/kdbus hooks either.  At least I don't think I 
ever really satisfied myself that what we had was the "right" solution.

We both got busy and kinda drifted away from this effort.  Karol, did you do 
any further work on the hooks?

-- 
paul moore
security and virtualization @ redhat

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 00/12] Add kdbus implementation

[One Thousand Gnomes]

> > The core calls are already mediated by LSM today, right?  We don't want
> > anyone to be parsing the data stream through an LSM, that idea got
> > rejected a long time ago as something that is really not a good idea.
> 
> Parsing data is out of question, of course, but this is not what we were
> proposing.

Why is it out of the question. If it's a socket you can just a BPF filter
on it, so why can't kdbus support similar basic functionality ?

Alan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 00/12] Add kdbus implementation

[Alex Elsayed]

Andy Lutomirski wrote:


> There should be a number measured in, say, nanoseconds in here
> somewhere.  The actual extent of the speedup is unmeasurable here.
> Also, it's worth reading at least one of Linus' many rants about
> zero-copy.  It's not an automatic win.

It's well-understood that it's not an automatic win; significant testing on 
multiple architectures indicated that 512K is a surprisingly universal 
crossover point. The userspace code, therefore, switches from copying 
(normal kdbus parameters) to zero-copy (memfds) right around there.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 00/12] Add kdbus implementation

[Greg Kroah-Hartman]

On Thu, Oct 30, 2014 at 08:55:56PM +0100, Karol Lewandowski wrote:
> On 2014-10-30 15:47, Greg Kroah-Hartman wrote:
> > On Thu, Oct 30, 2014 at 11:44:39AM +0100, Karol Lewandowski wrote:
> >> [ Sorry for breaking thread and resend - gmane rejected my original message
> >>   due to too long list of recipients... ]
> >>
> >> On 2014-10-30 00:40, Greg Kroah-Hartman wrote:
> >>
> >>> There is a 1815 line documentation file in this series, so we aren't
> >>> trying to not provide this type of information here at all.  But yes,
> >>> more background, about why this can't be done in userspace (zero copy,
> >>> less context switches, proper credential passing, timestamping, availble
> >>> at early-boot, LSM hooks for security models to tie into
> >>
> >> While you're at it... I did some work on proof-of-concept LSM patches for
> >> kdbus some time ago, see [1][2].  Currently, these are completely of date.
> >>
> >>  [1] https://github.com/lmctl/linux/commits/kdbus-lsm-v4.for-systemd-v212
> >>  [2] 
> >> https://github.com/lmctl/kdbus/commit/aa0885489d19be92fa41c6f0a71df28763228a40
> >>
> >> May I ask if you guys have your own plan for LSM or maybe it would be
> >> worth to resurrect [1]?
> > 
> > The core calls are already mediated by LSM today, right?  We don't want
> > anyone to be parsing the data stream through an LSM, that idea got
> > rejected a long time ago as something that is really not a good idea.
> 
> Parsing data is out of question, of course, but this is not what we were
> proposing.

Glad to hear it :)

> > Other than that, I don't know exactly what your patches do, or why they
> > are needed, care to go into details?
> 
> Patches in question were supposed to add few hooks for kdbus-specific
> operations that doesn't seem to have compatible semantics with hooks
> currently available in LSM.
> 
> kdbus' bus introduces quite a few new concepts that we wanted to be able
> to limit based on MAC label/context, eg.
> 
>  - check flags at HELO stage (say disallow fd passing),
> 
>  - restrict ability to acquire name to certain subjects (for system bus),
> 
>  - disallow creation of new buses,
> 
>  - limit scope of broadcasts,
> 
>  - etc.

Nice list.

> Please take a look at hook list - I think most of names are self-explanatory:
> 
>   
> https://github.com/lmctl/linux/blob/a9fe4c33b6e5ab25a243e0590df406aabb6add12/include/linux/security.h#L1874
> 
> kdbus modifications were pretty light - with most visible change being
> addition of opaque security pointer to kdbus_bus and similar structs.

That looks very reasonable, care to make it up into a patch I can add to
the end of this series so it's easy to review and possibly submit as
part of it?

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 00/12] Add kdbus implementation

[Karol Lewandowski]

On 2014-10-30 15:47, Greg Kroah-Hartman wrote:
> On Thu, Oct 30, 2014 at 11:44:39AM +0100, Karol Lewandowski wrote:
>> [ Sorry for breaking thread and resend - gmane rejected my original message
>>   due to too long list of recipients... ]
>>
>> On 2014-10-30 00:40, Greg Kroah-Hartman wrote:
>>
>>> There is a 1815 line documentation file in this series, so we aren't
>>> trying to not provide this type of information here at all.  But yes,
>>> more background, about why this can't be done in userspace (zero copy,
>>> less context switches, proper credential passing, timestamping, availble
>>> at early-boot, LSM hooks for security models to tie into
>>
>> While you're at it... I did some work on proof-of-concept LSM patches for
>> kdbus some time ago, see [1][2].  Currently, these are completely of date.
>>
>>  [1] https://github.com/lmctl/linux/commits/kdbus-lsm-v4.for-systemd-v212
>>  [2] 
>> https://github.com/lmctl/kdbus/commit/aa0885489d19be92fa41c6f0a71df28763228a40
>>
>> May I ask if you guys have your own plan for LSM or maybe it would be
>> worth to resurrect [1]?
> 
> The core calls are already mediated by LSM today, right?  We don't want
> anyone to be parsing the data stream through an LSM, that idea got
> rejected a long time ago as something that is really not a good idea.

Parsing data is out of question, of course, but this is not what we were
proposing.

> Other than that, I don't know exactly what your patches do, or why they
> are needed, care to go into details?

Patches in question were supposed to add few hooks for kdbus-specific
operations that doesn't seem to have compatible semantics with hooks
currently available in LSM.

kdbus' bus introduces quite a few new concepts that we wanted to be able
to limit based on MAC label/context, eg.

 - check flags at HELO stage (say disallow fd passing),

 - restrict ability to acquire name to certain subjects (for system bus),

 - disallow creation of new buses,

 - limit scope of broadcasts,

 - etc.

Please take a look at hook list - I think most of names are self-explanatory:

  
https://github.com/lmctl/linux/blob/a9fe4c33b6e5ab25a243e0590df406aabb6add12/include/linux/security.h#L1874

kdbus modifications were pretty light - with most visible change being
addition of opaque security pointer to kdbus_bus and similar structs.

Thanks!
-- 
Karol Lewandowski, Samsung R Institute Poland
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 00/12] Add kdbus implementation

[Greg Kroah-Hartman]

On Thu, Oct 30, 2014 at 09:33:56AM +0100, Arnd Bergmann wrote:
> On Wednesday 29 October 2014 15:00:44 Greg Kroah-Hartman wrote:
> >  drivers/misc/Kconfig |1 +
> >  drivers/misc/Makefile|1 +
> >  drivers/misc/kdbus/Kconfig   |   11 +
> >  drivers/misc/kdbus/Makefile  |   19 +
> >  drivers/misc/kdbus/bus.c |  450 ++
> >  drivers/misc/kdbus/bus.h |  107 ++
> >  drivers/misc/kdbus/connection.c  | 1751 
> > +
> >  drivers/misc/kdbus/connection.h  |  177 +++
> >  drivers/misc/kdbus/domain.c  |  477 ++
> > 
> 
> One very high-level common:
> 
> Since this is going to be a very commonly used IPC mechanism, I don't
> like the idea of stuffing it into drivers/misc.
> 
> How about putting it into drivers/kdbus or ipc/kdbus instead?

ipc/kdbus seems good to me.  I didn't want to "pollute" drivers/ with
any new subdirectories, it seems to grow fast enough as it is...

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 00/12] Add kdbus implementation

[Greg Kroah-Hartman]

On Thu, Oct 30, 2014 at 11:44:39AM +0100, Karol Lewandowski wrote:
> [ Sorry for breaking thread and resend - gmane rejected my original message
>   due to too long list of recipients... ]
> 
> On 2014-10-30 00:40, Greg Kroah-Hartman wrote:
> 
> > There is a 1815 line documentation file in this series, so we aren't
> > trying to not provide this type of information here at all.  But yes,
> > more background, about why this can't be done in userspace (zero copy,
> > less context switches, proper credential passing, timestamping, availble
> > at early-boot, LSM hooks for security models to tie into
> 
> While you're at it... I did some work on proof-of-concept LSM patches for
> kdbus some time ago, see [1][2].  Currently, these are completely of date.
> 
>  [1] https://github.com/lmctl/linux/commits/kdbus-lsm-v4.for-systemd-v212
>  [2] 
> https://github.com/lmctl/kdbus/commit/aa0885489d19be92fa41c6f0a71df28763228a40
> 
> May I ask if you guys have your own plan for LSM or maybe it would be
> worth to resurrect [1]?

The core calls are already mediated by LSM today, right?  We don't want
anyone to be parsing the data stream through an LSM, that idea got
rejected a long time ago as something that is really not a good idea.

Other than that, I don't know exactly what your patches do, or why they
are needed, care to go into details?

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 00/12] Add kdbus implementation

[Andy Lutomirski]

On Thu, Oct 30, 2014 at 4:52 AM, Tom Gundersen  wrote:
> On 10/30/2014 12:55 AM, Andy Lutomirski wrote:> It's worth noting that:
>>
>>  - Proper credential passing could be added to UNIX sockets, and we
>> may want to do that anyway.  Also, the current kdbus semantics seem to
>> be "spew lots of credentials and other miscellaneous
>> potentially-sensitive and sometime spoofable information all over the
>> place", which isn't obviously an improvement.  (This is fixable, but
>> it will almost certainly not be compatible with current systemd kdbus
>> code if fixed.)
>
> Care to elaborate on what you think is spoofable, and what needs to be fixed?

cmd and comm are trivially replaceable by any sender.

>
> Anyway, the idea is that by simply connecting to the bus and sending a
> message to some service, you implicitly agree to passing some metadata
> along to the service (and to a lesser extent to the bus). It's not
> that this information is leaked, or that the peer could actively
> access any of the sender's private memory.

To me, this smells like bad design.  By using kdbus, I implicitly
agree to send everyone my command line?!?  If I'm in a cgroup that
policy decrees should be privileged, then I should invoke that
privilege by specifically asking, *at the time of capture*, to send
that cgroup.  Otherwise it becomes unclear what things convey
privilege when, and that will lead immediately to incomprehensible
security models, and that will lead to exploits.

Sorry, but "implicitly agree" sounds a lot like using my
esteemed cellphone carrier.  When I use it, some argue that I
implicitly agree to have my identity prepended to all outgoing HTTP
requests.  This is *not* a good thing.

> Also note that this kind of
> metadata information is also available via /proc/$PID, and via
> SCM_CREDENTIALS/SO_PEERCRED and the socket seclabel APIs.

Not if you have a sensible LSM policy or if you use hidepid.  And,
once you've fixed the namespacing issues, not if the sender and
receiver are in different PID namespaces or if they don't have /proc
mounted at all.

>
> When credential information is passed between processes of different
> (PID) namespaces most of the attached metadata is suppressed.

This is a bug.  It prevents users from usefully sandboxing themselves
in a kdbus world.  If you create and enter a user namespace, then your
outside identity (which should be unchanged) is suppressed.  (Note
that anything that captures credentials other than at open time is
also an issue for sandboxes in the other direction: it may interfere
with selective privilege dropping.)

> This
> isn't too different from how SCM_CREDENTIALS works, which will zero
> out the bits it cannot translate as well.

SCM_CREDENTIALS translates the translatable parts.

> There are some major benefits regarding performance:
>
> * fewer userspace context switches. For a full-duplex method call it's
> down from five to two: instead of sender -> dbus daemon -> service ->
> dbus daemon -> sender it's just sender -> service -> sender.
> * fewer message copies in userspace. For a full-duplex method call
> it's down from eight to two: instead of copying the method call data
> into a socket, out of a socket, into a socket, out of a socket, and
> the same for the method reply, we just copy one message directly to
> the receiver, and the reply back.
> * generally fewer syscalls involved. A synchronous method call is now
> doable in a single ioctl on the sender side.
> * memfds can be used for transport purposes of larger payload. This
> way, we can cover substantial payload sizes instead of just small
> control messages, with no extra copies. kdbus, in its transport layer,
> makes sure only sealed memfds are passed in as payload, so the sender
> cannot modify the contents while the receiver is already parsing it.

There should be a number measured in, say, nanoseconds in here
somewhere.  The actual extent of the speedup is unmeasurable here.
Also, it's worth reading at least one of Linus' many rants about
zero-copy.  It's not an automatic win.

--Andy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 00/12] Add kdbus implementation

[Andy Lutomirski]

On Thu, Oct 30, 2014 at 3:15 AM, Tom Gundersen  wrote:
> Do I understand you correctly that what you want is unnamed/anonymous
> domains? Considering that domain creation is anyway privileged, why is
> this necessary?

As an executive summary, this is the *problem*, not a mitigation.
Domain creation *should not require privilege*.  You should be able to
do it in a user namespace in which you have appropriate capabilities
without needing systemd's (or whatever other daemon's) help from
outside.

Once you fix that (which may not have broken whatever you tested with
but will absolutely break anyone who tries to use this in LXC, Docker,
Sandstorm, etc. without awful hacks) then you will have all of the
problems that you've currently mitigated.

--Andy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 00/12] Add kdbus implementation

[Simon McVittie]

On 30/10/14 11:52, Tom Gundersen wrote:
> For example, if you want to get the audit identity
> bits, you can now get this attached securely by the kernel, at the
> time the message is sent, rather than having to firest get the peer's
> $PID from SCM_CREDENTIALS and then read the audit identity bits racily
> from /proc/$PID/loginuid and /proc/$PID/sessionid

... which dbus-daemon (traditional D-Bus) deliberately doesn't offer as
a feature, because we are not aware of any way to do that over Unix
sockets without a race condition; and if we can't have it securely, we
don't want to have it at all.

It would be great if kdbus can fix that omission.

Capabilities are in the same boat, and as a result, systemd can't
currently have D-Bus methods that can only be called with CAP_WHATEVER.

> * fewer userspace context switches
[...]
> * fewer message copies in userspace

Readers are probably already aware of this, but note that D-Bus is
designed to be usable between mutually distrusting processes, which is
why we use Unix sockets and a lot of copies, rather than mmap or something.

S

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 00/12] Add kdbus implementation

[Eric W. Biederman]

Tom Gundersen  writes:

> Hi Eric,
>
> On Thu, Oct 30, 2014 at 5:20 AM, Eric W. Biederman
>  wrote:
>> The userspace API breaks userspace in an unfixable way.
>>
>> Nacked-by: "Eric W. Biederman" 
>>
>> Problem the first.
>> - Using global names for containers makes it impossible to create
>>   unprivileged containers.
>
> I don't follow.
>
> Just so we are on the same page:
>   - creating a domain per container is only a convention, and has to
> be done manually. I.e., the worst case scenario is that you are able
> to create some container which cannot get a corresponding kdbus
> domain.

Which is the classic definition of failure to restore a checkpoint.  You
can't get the name you needed.

>   - domain names are only unique per parent-domain, and domains are
> fully recursive. We explicitly tested recursive domains by running
> kdbus-enabled containers within kdbus-enabled containers, a number of
> iterations deep.
>
> Could you explain the problem you see in more detail? This might just
> be a documenation issue, after all.

Partly there is just a ridiculous amount of complexity in having
hiearchical names when there is fundamentally no hierarchy.

The problem I see is that creating a kdbus requires someone to grant you
privilege to do it.  You have to ask permission from the system
administrator.  For unprivileged containers you don't have to ask
permission to create one, you just need the appropriate support in your
kernel.

Given the fact you smash all of the names together in a hierarchy I
can't see how you can avoid requiring privilege for part of the
hierarchy creation.

>>   This is a back to the drawing board problem, and makes device
>>   nodes fundamentally unsuited to what you are doing.
>>
>>   There is no way that I can see to make it safe for an unprivileged
>>   user to create arbitrary named busses.  Especially in the presence
>>   of allowing unprivileged checkpoint/restart.
>
> Note that unprivileged users cannot create arbitrary named busses, the
> names must have the format $PID-. Do you see a problem
> with this?

Yes.  What pid namespace is that in?

How do I restore a checkpoint?

>>   This is particularly bad as kdbus explicitly allows unprivielged
>>   creation of new kdbus instances.
>
> What do you mean by kdbus instance? A new domain? This is not allowed
> by unprivileged processes. Or do you mean a new bus, in which case see
> above.

Oh great two concepts domains and busses.  The bottom line if I can't
create both unprivileged it is a regression in the functionality of
unprivileged containers.

>>   This problem is a userspace regression.
>
> This is all new functionality, how does it affect current code?

If you simply change the existing dbus users to use kdbus you get a
regression in containers.  Furthermore you get a regression in what
kinds of userspace a container can contain.

>> Problem the second.
>> - The security checks in the code are not based on who opens the
>>   file descriptors but instead based on who is used the file
>>   descriptors at any give moment.
>>
>>   That pattern has been shown to be exploitable.
>>
>>   I expect the policy database makes this poor choice of permission
>>   checks even worse.  Pass a more privileged user a kdbus file
>>   descriptor and all of sudden things that were not possible on
>>   that file descriptor become possible.
>
> Djalal already commented on this point in another thread. But just to
> recap: Please note that we do not do read()/write() at all, only
> ioctl's, so the most common exploits do not apply. Moreover, we are
> following the same API pattern as used by other similar APIs in the
> kernel. 

A pattern that has led to an exploitable kernel, because it breaks the
principle of least surprise.

> With that in mind, could you give some more specific
> information about what kind of exploits you imagine?

I don't know if it is exploitable or simply a maintenance disaster.  But
the behavior of file descriptors changing based on who is performing
operations on it is wrong.  It breaks the common unix expectations.

It means I can not pass a file descriptor into a strongly sandboxed
application and be able to predict what can be done with the file
descriptor in the sand box.

I suspect what you really want are system calls.  As system calls are
both less overhead and easier to understand what is going on.
Especially for something as commonly used as kdbus is aiming to be
ioctls seem like code obfuscation.

The easiest problem to trigger that I can imagine is an application that
calls setresuid will have unpredicatable behavior if the change their
effective uid happens between one call and the next of your ioctl.
Which can create subtle and difficult to find bugs.

There are also all kinds of issues with respect to namespaces that if
you care about the namespace you are referring to has to be pinned at
open time.

>> Problem the third.
>> - You are using device numbers for things created by unprivileged
>>   users.  

Re: [PATCH 00/12] Add kdbus implementation

[Tom Gundersen]

On 10/30/2014 12:55 AM, Andy Lutomirski wrote:> It's worth noting that:
>
>  - Proper credential passing could be added to UNIX sockets, and we
> may want to do that anyway.  Also, the current kdbus semantics seem to
> be "spew lots of credentials and other miscellaneous
> potentially-sensitive and sometime spoofable information all over the
> place", which isn't obviously an improvement.  (This is fixable, but
> it will almost certainly not be compatible with current systemd kdbus
> code if fixed.)

Care to elaborate on what you think is spoofable, and what needs to be fixed?

Anyway, the idea is that by simply connecting to the bus and sending a
message to some service, you implicitly agree to passing some metadata
along to the service (and to a lesser extent to the bus). It's not
that this information is leaked, or that the peer could actively
access any of the sender's private memory. Also note that this kind of
metadata information is also available via /proc/$PID, and via
SCM_CREDENTIALS/SO_PEERCRED and the socket seclabel APIs. What the
kdbus API allows users to do is to get a lot more of this information
in a race-free way. For example, if you want to get the audit identity
bits, you can now get this attached securely by the kernel, at the
time the message is sent, rather than having to firest get the peer's
$PID from SCM_CREDENTIALS and then read the audit identity bits racily
from /proc/$PID/loginuid and /proc/$PID/sessionid.

>  - The current kdbus patches seem to be worse than UNIX sockets from a
> namespace perspective, but maybe I'm misunderstanding how it's
> supposed to work.  UNIX sockets work quite nicely in containers.

kdbus is recusively stackable for containers. You can run
kdbus-enabled containers within kdbus-enabled containers within
kdbus-enabled containers, with the full functionality available for
each container, and each container isolated from each other.

When credential information is passed between processes of different
(PID) namespaces most of the attached metadata is suppressed. This
isn't too different from how SCM_CREDENTIALS works, which will zero
out the bits it cannot translate as well.

>  - There's an obvious interface to add timestamping to UNIX sockets
> (it could work exactly the way it does for UDP / PTP).

Timestamping on AF_UNIX/SOCK_DGRAM already exists, but that's not
enough for the use-cases we want to support.

>  - I'm unconvinced by this performance argument without numbers.  The
> kdbus credential code, at least, looks to be quite heavy on allocation
> and atomics.  This isn't to say that the current userspace D-Bus
> daemon doesn't also serialize everything, but it could be made
> multithreaded.

There are some major benefits regarding performance:

* fewer userspace context switches. For a full-duplex method call it's
down from five to two: instead of sender -> dbus daemon -> service ->
dbus daemon -> sender it's just sender -> service -> sender.
* fewer message copies in userspace. For a full-duplex method call
it's down from eight to two: instead of copying the method call data
into a socket, out of a socket, into a socket, out of a socket, and
the same for the method reply, we just copy one message directly to
the receiver, and the reply back.
* generally fewer syscalls involved. A synchronous method call is now
doable in a single ioctl on the sender side.
* memfds can be used for transport purposes of larger payload. This
way, we can cover substantial payload sizes instead of just small
control messages, with no extra copies. kdbus, in its transport layer,
makes sure only sealed memfds are passed in as payload, so the sender
cannot modify the contents while the receiver is already parsing it.

>  - Race-free?  What are the races that are inherent to UNIX sockets?

Does the above explain what we have in mind?

Note that the aim is not necessarily that kdbus should be better than
UNIX sockets in every way, nor that it should be favoured in all
cases. What we are trying to address is a common case in environments
where peers don't necessarily trust each other.

Cheers,

Tom
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 00/12] Add kdbus implementation

[Karol Lewandowski]

[ Sorry for breaking thread and resend - gmane rejected my original message
  due to too long list of recipients... ]

On 2014-10-30 00:40, Greg Kroah-Hartman wrote:

> There is a 1815 line documentation file in this series, so we aren't
> trying to not provide this type of information here at all.  But yes,
> more background, about why this can't be done in userspace (zero copy,
> less context switches, proper credential passing, timestamping, availble
> at early-boot, LSM hooks for security models to tie into

While you're at it... I did some work on proof-of-concept LSM patches for
kdbus some time ago, see [1][2].  Currently, these are completely of date.

 [1] https://github.com/lmctl/linux/commits/kdbus-lsm-v4.for-systemd-v212
 [2] 
https://github.com/lmctl/kdbus/commit/aa0885489d19be92fa41c6f0a71df28763228a40

May I ask if you guys have your own plan for LSM or maybe it would be
worth to resurrect [1]?

Cheers,
-- 
Karol Lewandowski, Samsung R Institute Poland



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 00/12] Add kdbus implementation

[Tom Gundersen]

Hi Eric,

On Thu, Oct 30, 2014 at 5:20 AM, Eric W. Biederman
 wrote:
> The userspace API breaks userspace in an unfixable way.
>
> Nacked-by: "Eric W. Biederman" 
>
> Problem the first.
> - Using global names for containers makes it impossible to create
>   unprivileged containers.

I don't follow.

Just so we are on the same page:
  - creating a domain per container is only a convention, and has to
be done manually. I.e., the worst case scenario is that you are able
to create some container which cannot get a corresponding kdbus
domain.
  - domain names are only unique per parent-domain, and domains are
fully recursive. We explicitly tested recursive domains by running
kdbus-enabled containers within kdbus-enabled containers, a number of
iterations deep.

Could you explain the problem you see in more detail? This might just
be a documenation issue, after all.

>   This is a back to the drawing board problem, and makes device
>   nodes fundamentally unsuited to what you are doing.
>
>   There is no way that I can see to make it safe for an unprivileged
>   user to create arbitrary named busses.  Especially in the presence
>   of allowing unprivileged checkpoint/restart.

Note that unprivileged users cannot create arbitrary named busses, the
names must have the format $PID-. Do you see a problem
with this?

>   This is particularly bad as kdbus explicitly allows unprivielged
>   creation of new kdbus instances.

What do you mean by kdbus instance? A new domain? This is not allowed
by unprivileged processes. Or do you mean a new bus, in which case see
above.

>   This problem is a userspace regression.

This is all new functionality, how does it affect current code?

> Problem the second.
> - The security checks in the code are not based on who opens the
>   file descriptors but instead based on who is used the file
>   descriptors at any give moment.
>
>   That pattern has been shown to be exploitable.
>
>   I expect the policy database makes this poor choice of permission
>   checks even worse.  Pass a more privileged user a kdbus file
>   descriptor and all of sudden things that were not possible on
>   that file descriptor become possible.

Djalal already commented on this point in another thread. But just to
recap: Please note that we do not do read()/write() at all, only
ioctl's, so the most common exploits do not apply. Moreover, we are
following the same API pattern as used by other similar APIs in the
kernel. With that in mind, could you give some more specific
information about what kind of exploits you imagine?

> Problem the third.
> - You are using device numbers for things created by unprivileged
>   users.  That breaks checkpoint/restart.  Aka CRIU.
>
>   We can not migrate a container to a new machine and preserve the
>   device numbers.

I must admit to not being too familiar with checkpoint/restart. What
precisely is the problem with unprivileged users?

>   We can not migrate a container to a new machine and have any hope
>   of preserving the container patsh under /dev/kdbus/...

You may not be able to preserve the full path, no, but the container
should not know/care about the parent paths anyway.  Note that the
containers only see their own domain subtree mounted to /dev/kdbus,
they see nothing from the parent. Hence when you migrate containers
you can change the naming of the parent freely, but the processes
inside the containers won't see that, they'll have stable paths.   I'm
not seeing the problem here, care to elaborate?

> I think a kdbusfs modeled on devpts with newinstance at
> mount time would solve the naming problems.

Effectively, what we have in place in the current patch set delivers
similar semantics, however without introducing a new file system. You
just create a new domain and get a new subdir in /dev/kdbus/ for it,
and then inside the container you mount that subdir of /dev/kdbus onto
/dev/kdbus itself.

Do I understand you correctly that what you want is unnamed/anonymous
domains? Considering that domain creation is anyway privileged, why is
this necessary?

> That would break one of the current kdbus use cases that allows an
> unprivileged user to create a bus.

That is a fundamental usecase, so I don't think it makes much sense to
do anything that precludes that.

Cheers,

Tom
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 00/12] Add kdbus implementation

[Karol Lewandowski]

On 2014-10-30 00:40, Greg Kroah-Hartman wrote:

> There is a 1815 line documentation file in this series, so we aren't
> trying to not provide this type of information here at all.  But yes,
> more background, about why this can't be done in userspace (zero copy,
> less context switches, proper credential passing, timestamping, availble
> at early-boot, LSM hooks for security models to tie into

While you're at it... I have worked on proof-of-concept LSM patches for
kdbus some time ago, see [1][2].  Currently, these are completely of date.

 [1] https://github.com/lmctl/linux/commits/kdbus-lsm-v4.for-systemd-v212
 [2] 
https://github.com/lmctl/kdbus/commit/aa0885489d19be92fa41c6f0a71df28763228a40

May I ask if you guys have your own plan for LSM or maybe it would be
worth to resurrect [1]?

Cheers,
-- 
Karol Lewandowski, Samsung R Institute Poland


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 00/12] Add kdbus implementation

[Arnd Bergmann]

On Wednesday 29 October 2014 15:00:44 Greg Kroah-Hartman wrote:
>  drivers/misc/Kconfig |1 +
>  drivers/misc/Makefile|1 +
>  drivers/misc/kdbus/Kconfig   |   11 +
>  drivers/misc/kdbus/Makefile  |   19 +
>  drivers/misc/kdbus/bus.c |  450 ++
>  drivers/misc/kdbus/bus.h |  107 ++
>  drivers/misc/kdbus/connection.c  | 1751 +
>  drivers/misc/kdbus/connection.h  |  177 +++
>  drivers/misc/kdbus/domain.c  |  477 ++
> 

One very high-level common:

Since this is going to be a very commonly used IPC mechanism, I don't
like the idea of stuffing it into drivers/misc.

How about putting it into drivers/kdbus or ipc/kdbus instead?

Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 00/12] Add kdbus implementation

[Daniel Mack]

On 10/29/2014 11:28 PM, Andy Lutomirski wrote:
> On Wed, Oct 29, 2014 at 3:25 PM, Greg Kroah-Hartman

>> You do have to opt-in for this information at time of capture, so
>> I don't understand the issue here.  This is the same type of thing
>> that dbus does today, and I don't see the information leaks
>> happening there, do you?
> 
> The docs suggest that the *receiver* opts in.

Yes, that's true.

> I don't think that current dbus has severe information leaks because 
> the total scope for information transparently sent to dbus is rather 
> small (struct ucred only, presumably).

Which piece of credential information are you concerned about,
particularly? I might miss something, but AFAICS, all of that
information can be queried by a remote peer anyway, through /proc for
instance. The reason why we (optionally) attach them to messages is that
we want to let the other side know which information was authoritative,
precisely at the time the message was sent. Current implementation can't
do that in a race-free way.

Also note that we currently drop all such metadata whenever a message
crosses a PID or user namespace boundary. This is because we currently
don't know yet which information we would want to transport in such
cases, and how the translation in both directions would look like, from
a semantic perspective. Hence, we decided to leave that for later.

I'll go through your other replies during the day. Thanks for your input
on that RFC, everyone.


Daniel
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 00/12] Add kdbus implementation

[Daniel Mack]

On 10/30/2014 05:04 AM, Eric W. Biederman wrote:
> For what it is worth these patches are also poorly split up.  Every
> patch I looked at in detail had functions that were being introduced
> that did not have callers.

Yes, we wanted to keep the reply threading cleaner and the individual
patches short. With a patch set that avoids introducing functions
without callers, each patch would have grown substantially. But I know
that's unusual to do it that way.

> That poor split up of the patches makes it difficult to see how
> the functionality that is being introduced is being used.

Ok, I see. For now, I think it's probably easiest to pull the patches
from here, and then look at the resulting files directly:


https://git.kernel.org/cgit/linux/kernel/git/gregkh/char-misc.git/log/?h=kdbus

Other than that, please give us some time to respond to your longer
reply. Thanks for taking the time to write this up!


Daniel

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 00/12] Add kdbus implementation

[Daniel Mack]

On 10/30/2014 05:04 AM, Eric W. Biederman wrote:
 For what it is worth these patches are also poorly split up.  Every
 patch I looked at in detail had functions that were being introduced
 that did not have callers.

Yes, we wanted to keep the reply threading cleaner and the individual
patches short. With a patch set that avoids introducing functions
without callers, each patch would have grown substantially. But I know
that's unusual to do it that way.

 That poor split up of the patches makes it difficult to see how
 the functionality that is being introduced is being used.

Ok, I see. For now, I think it's probably easiest to pull the patches
from here, and then look at the resulting files directly:


https://git.kernel.org/cgit/linux/kernel/git/gregkh/char-misc.git/log/?h=kdbus

Other than that, please give us some time to respond to your longer
reply. Thanks for taking the time to write this up!


Daniel

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 00/12] Add kdbus implementation

[Daniel Mack]

On 10/29/2014 11:28 PM, Andy Lutomirski wrote:
 On Wed, Oct 29, 2014 at 3:25 PM, Greg Kroah-Hartman

 You do have to opt-in for this information at time of capture, so
 I don't understand the issue here.  This is the same type of thing
 that dbus does today, and I don't see the information leaks
 happening there, do you?
 
 The docs suggest that the *receiver* opts in.

Yes, that's true.

 I don't think that current dbus has severe information leaks because 
 the total scope for information transparently sent to dbus is rather 
 small (struct ucred only, presumably).

Which piece of credential information are you concerned about,
particularly? I might miss something, but AFAICS, all of that
information can be queried by a remote peer anyway, through /proc for
instance. The reason why we (optionally) attach them to messages is that
we want to let the other side know which information was authoritative,
precisely at the time the message was sent. Current implementation can't
do that in a race-free way.

Also note that we currently drop all such metadata whenever a message
crosses a PID or user namespace boundary. This is because we currently
don't know yet which information we would want to transport in such
cases, and how the translation in both directions would look like, from
a semantic perspective. Hence, we decided to leave that for later.

I'll go through your other replies during the day. Thanks for your input
on that RFC, everyone.


Daniel
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 00/12] Add kdbus implementation

[Arnd Bergmann]

On Wednesday 29 October 2014 15:00:44 Greg Kroah-Hartman wrote:
  drivers/misc/Kconfig |1 +
  drivers/misc/Makefile|1 +
  drivers/misc/kdbus/Kconfig   |   11 +
  drivers/misc/kdbus/Makefile  |   19 +
  drivers/misc/kdbus/bus.c |  450 ++
  drivers/misc/kdbus/bus.h |  107 ++
  drivers/misc/kdbus/connection.c  | 1751 +
  drivers/misc/kdbus/connection.h  |  177 +++
  drivers/misc/kdbus/domain.c  |  477 ++
 

One very high-level common:

Since this is going to be a very commonly used IPC mechanism, I don't
like the idea of stuffing it into drivers/misc.

How about putting it into drivers/kdbus or ipc/kdbus instead?

Arnd
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 00/12] Add kdbus implementation

[Karol Lewandowski]

On 2014-10-30 00:40, Greg Kroah-Hartman wrote:

 There is a 1815 line documentation file in this series, so we aren't
 trying to not provide this type of information here at all.  But yes,
 more background, about why this can't be done in userspace (zero copy,
 less context switches, proper credential passing, timestamping, availble
 at early-boot, LSM hooks for security models to tie into

While you're at it... I have worked on proof-of-concept LSM patches for
kdbus some time ago, see [1][2].  Currently, these are completely of date.

 [1] https://github.com/lmctl/linux/commits/kdbus-lsm-v4.for-systemd-v212
 [2] 
https://github.com/lmctl/kdbus/commit/aa0885489d19be92fa41c6f0a71df28763228a40

May I ask if you guys have your own plan for LSM or maybe it would be
worth to resurrect [1]?

Cheers,
-- 
Karol Lewandowski, Samsung RD Institute Poland


--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 00/12] Add kdbus implementation

[Tom Gundersen]

Hi Eric,

On Thu, Oct 30, 2014 at 5:20 AM, Eric W. Biederman
ebied...@xmission.com wrote:
 The userspace API breaks userspace in an unfixable way.

 Nacked-by: Eric W. Biederman ebied...@xmission.com

 Problem the first.
 - Using global names for containers makes it impossible to create
   unprivileged containers.

I don't follow.

Just so we are on the same page:
  - creating a domain per container is only a convention, and has to
be done manually. I.e., the worst case scenario is that you are able
to create some container which cannot get a corresponding kdbus
domain.
  - domain names are only unique per parent-domain, and domains are
fully recursive. We explicitly tested recursive domains by running
kdbus-enabled containers within kdbus-enabled containers, a number of
iterations deep.

Could you explain the problem you see in more detail? This might just
be a documenation issue, after all.

   This is a back to the drawing board problem, and makes device
   nodes fundamentally unsuited to what you are doing.

   There is no way that I can see to make it safe for an unprivileged
   user to create arbitrary named busses.  Especially in the presence
   of allowing unprivileged checkpoint/restart.

Note that unprivileged users cannot create arbitrary named busses, the
names must have the format $PID-arbitrary name. Do you see a problem
with this?

   This is particularly bad as kdbus explicitly allows unprivielged
   creation of new kdbus instances.

What do you mean by kdbus instance? A new domain? This is not allowed
by unprivileged processes. Or do you mean a new bus, in which case see
above.

   This problem is a userspace regression.

This is all new functionality, how does it affect current code?

 Problem the second.
 - The security checks in the code are not based on who opens the
   file descriptors but instead based on who is used the file
   descriptors at any give moment.

   That pattern has been shown to be exploitable.

   I expect the policy database makes this poor choice of permission
   checks even worse.  Pass a more privileged user a kdbus file
   descriptor and all of sudden things that were not possible on
   that file descriptor become possible.

Djalal already commented on this point in another thread. But just to
recap: Please note that we do not do read()/write() at all, only
ioctl's, so the most common exploits do not apply. Moreover, we are
following the same API pattern as used by other similar APIs in the
kernel. With that in mind, could you give some more specific
information about what kind of exploits you imagine?

 Problem the third.
 - You are using device numbers for things created by unprivileged
   users.  That breaks checkpoint/restart.  Aka CRIU.

   We can not migrate a container to a new machine and preserve the
   device numbers.

I must admit to not being too familiar with checkpoint/restart. What
precisely is the problem with unprivileged users?

   We can not migrate a container to a new machine and have any hope
   of preserving the container patsh under /dev/kdbus/...

You may not be able to preserve the full path, no, but the container
should not know/care about the parent paths anyway.  Note that the
containers only see their own domain subtree mounted to /dev/kdbus,
they see nothing from the parent. Hence when you migrate containers
you can change the naming of the parent freely, but the processes
inside the containers won't see that, they'll have stable paths.   I'm
not seeing the problem here, care to elaborate?

 I think a kdbusfs modeled on devpts with newinstance at
 mount time would solve the naming problems.

Effectively, what we have in place in the current patch set delivers
similar semantics, however without introducing a new file system. You
just create a new domain and get a new subdir in /dev/kdbus/ for it,
and then inside the container you mount that subdir of /dev/kdbus onto
/dev/kdbus itself.

Do I understand you correctly that what you want is unnamed/anonymous
domains? Considering that domain creation is anyway privileged, why is
this necessary?

 That would break one of the current kdbus use cases that allows an
 unprivileged user to create a bus.

That is a fundamental usecase, so I don't think it makes much sense to
do anything that precludes that.

Cheers,

Tom
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 00/12] Add kdbus implementation

[Karol Lewandowski]

[ Sorry for breaking thread and resend - gmane rejected my original message
  due to too long list of recipients... ]

On 2014-10-30 00:40, Greg Kroah-Hartman wrote:

 There is a 1815 line documentation file in this series, so we aren't
 trying to not provide this type of information here at all.  But yes,
 more background, about why this can't be done in userspace (zero copy,
 less context switches, proper credential passing, timestamping, availble
 at early-boot, LSM hooks for security models to tie into

While you're at it... I did some work on proof-of-concept LSM patches for
kdbus some time ago, see [1][2].  Currently, these are completely of date.

 [1] https://github.com/lmctl/linux/commits/kdbus-lsm-v4.for-systemd-v212
 [2] 
https://github.com/lmctl/kdbus/commit/aa0885489d19be92fa41c6f0a71df28763228a40

May I ask if you guys have your own plan for LSM or maybe it would be
worth to resurrect [1]?

Cheers,
-- 
Karol Lewandowski, Samsung RD Institute Poland



--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 00/12] Add kdbus implementation

[Tom Gundersen]

On 10/30/2014 12:55 AM, Andy Lutomirski wrote: It's worth noting that:

  - Proper credential passing could be added to UNIX sockets, and we
 may want to do that anyway.  Also, the current kdbus semantics seem to
 be spew lots of credentials and other miscellaneous
 potentially-sensitive and sometime spoofable information all over the
 place, which isn't obviously an improvement.  (This is fixable, but
 it will almost certainly not be compatible with current systemd kdbus
 code if fixed.)

Care to elaborate on what you think is spoofable, and what needs to be fixed?

Anyway, the idea is that by simply connecting to the bus and sending a
message to some service, you implicitly agree to passing some metadata
along to the service (and to a lesser extent to the bus). It's not
that this information is leaked, or that the peer could actively
access any of the sender's private memory. Also note that this kind of
metadata information is also available via /proc/$PID, and via
SCM_CREDENTIALS/SO_PEERCRED and the socket seclabel APIs. What the
kdbus API allows users to do is to get a lot more of this information
in a race-free way. For example, if you want to get the audit identity
bits, you can now get this attached securely by the kernel, at the
time the message is sent, rather than having to firest get the peer's
$PID from SCM_CREDENTIALS and then read the audit identity bits racily
from /proc/$PID/loginuid and /proc/$PID/sessionid.

  - The current kdbus patches seem to be worse than UNIX sockets from a
 namespace perspective, but maybe I'm misunderstanding how it's
 supposed to work.  UNIX sockets work quite nicely in containers.

kdbus is recusively stackable for containers. You can run
kdbus-enabled containers within kdbus-enabled containers within
kdbus-enabled containers, with the full functionality available for
each container, and each container isolated from each other.

When credential information is passed between processes of different
(PID) namespaces most of the attached metadata is suppressed. This
isn't too different from how SCM_CREDENTIALS works, which will zero
out the bits it cannot translate as well.

  - There's an obvious interface to add timestamping to UNIX sockets
 (it could work exactly the way it does for UDP / PTP).

Timestamping on AF_UNIX/SOCK_DGRAM already exists, but that's not
enough for the use-cases we want to support.

  - I'm unconvinced by this performance argument without numbers.  The
 kdbus credential code, at least, looks to be quite heavy on allocation
 and atomics.  This isn't to say that the current userspace D-Bus
 daemon doesn't also serialize everything, but it could be made
 multithreaded.

There are some major benefits regarding performance:

* fewer userspace context switches. For a full-duplex method call it's
down from five to two: instead of sender - dbus daemon - service -
dbus daemon - sender it's just sender - service - sender.
* fewer message copies in userspace. For a full-duplex method call
it's down from eight to two: instead of copying the method call data
into a socket, out of a socket, into a socket, out of a socket, and
the same for the method reply, we just copy one message directly to
the receiver, and the reply back.
* generally fewer syscalls involved. A synchronous method call is now
doable in a single ioctl on the sender side.
* memfds can be used for transport purposes of larger payload. This
way, we can cover substantial payload sizes instead of just small
control messages, with no extra copies. kdbus, in its transport layer,
makes sure only sealed memfds are passed in as payload, so the sender
cannot modify the contents while the receiver is already parsing it.

  - Race-free?  What are the races that are inherent to UNIX sockets?

Does the above explain what we have in mind?

Note that the aim is not necessarily that kdbus should be better than
UNIX sockets in every way, nor that it should be favoured in all
cases. What we are trying to address is a common case in environments
where peers don't necessarily trust each other.

Cheers,

Tom
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 00/12] Add kdbus implementation

[Eric W. Biederman]

Tom Gundersen t...@jklm.no writes:

 Hi Eric,

 On Thu, Oct 30, 2014 at 5:20 AM, Eric W. Biederman
 ebied...@xmission.com wrote:
 The userspace API breaks userspace in an unfixable way.

 Nacked-by: Eric W. Biederman ebied...@xmission.com

 Problem the first.
 - Using global names for containers makes it impossible to create
   unprivileged containers.

 I don't follow.

 Just so we are on the same page:
   - creating a domain per container is only a convention, and has to
 be done manually. I.e., the worst case scenario is that you are able
 to create some container which cannot get a corresponding kdbus
 domain.

Which is the classic definition of failure to restore a checkpoint.  You
can't get the name you needed.

   - domain names are only unique per parent-domain, and domains are
 fully recursive. We explicitly tested recursive domains by running
 kdbus-enabled containers within kdbus-enabled containers, a number of
 iterations deep.

 Could you explain the problem you see in more detail? This might just
 be a documenation issue, after all.

Partly there is just a ridiculous amount of complexity in having
hiearchical names when there is fundamentally no hierarchy.

The problem I see is that creating a kdbus requires someone to grant you
privilege to do it.  You have to ask permission from the system
administrator.  For unprivileged containers you don't have to ask
permission to create one, you just need the appropriate support in your
kernel.

Given the fact you smash all of the names together in a hierarchy I
can't see how you can avoid requiring privilege for part of the
hierarchy creation.

   This is a back to the drawing board problem, and makes device
   nodes fundamentally unsuited to what you are doing.

   There is no way that I can see to make it safe for an unprivileged
   user to create arbitrary named busses.  Especially in the presence
   of allowing unprivileged checkpoint/restart.

 Note that unprivileged users cannot create arbitrary named busses, the
 names must have the format $PID-arbitrary name. Do you see a problem
 with this?

Yes.  What pid namespace is that in?

How do I restore a checkpoint?

   This is particularly bad as kdbus explicitly allows unprivielged
   creation of new kdbus instances.

 What do you mean by kdbus instance? A new domain? This is not allowed
 by unprivileged processes. Or do you mean a new bus, in which case see
 above.

Oh great two concepts domains and busses.  The bottom line if I can't
create both unprivileged it is a regression in the functionality of
unprivileged containers.

   This problem is a userspace regression.

 This is all new functionality, how does it affect current code?

If you simply change the existing dbus users to use kdbus you get a
regression in containers.  Furthermore you get a regression in what
kinds of userspace a container can contain.

 Problem the second.
 - The security checks in the code are not based on who opens the
   file descriptors but instead based on who is used the file
   descriptors at any give moment.

   That pattern has been shown to be exploitable.

   I expect the policy database makes this poor choice of permission
   checks even worse.  Pass a more privileged user a kdbus file
   descriptor and all of sudden things that were not possible on
   that file descriptor become possible.

 Djalal already commented on this point in another thread. But just to
 recap: Please note that we do not do read()/write() at all, only
 ioctl's, so the most common exploits do not apply. Moreover, we are
 following the same API pattern as used by other similar APIs in the
 kernel. 

A pattern that has led to an exploitable kernel, because it breaks the
principle of least surprise.

 With that in mind, could you give some more specific
 information about what kind of exploits you imagine?

I don't know if it is exploitable or simply a maintenance disaster.  But
the behavior of file descriptors changing based on who is performing
operations on it is wrong.  It breaks the common unix expectations.

It means I can not pass a file descriptor into a strongly sandboxed
application and be able to predict what can be done with the file
descriptor in the sand box.

I suspect what you really want are system calls.  As system calls are
both less overhead and easier to understand what is going on.
Especially for something as commonly used as kdbus is aiming to be
ioctls seem like code obfuscation.

The easiest problem to trigger that I can imagine is an application that
calls setresuid will have unpredicatable behavior if the change their
effective uid happens between one call and the next of your ioctl.
Which can create subtle and difficult to find bugs.

There are also all kinds of issues with respect to namespaces that if
you care about the namespace you are referring to has to be pinned at
open time.

 Problem the third.
 - You are using device numbers for things created by unprivileged
   users.  That breaks 

Re: [PATCH 00/12] Add kdbus implementation

[Simon McVittie]

On 30/10/14 11:52, Tom Gundersen wrote:
 For example, if you want to get the audit identity
 bits, you can now get this attached securely by the kernel, at the
 time the message is sent, rather than having to firest get the peer's
 $PID from SCM_CREDENTIALS and then read the audit identity bits racily
 from /proc/$PID/loginuid and /proc/$PID/sessionid

... which dbus-daemon (traditional D-Bus) deliberately doesn't offer as
a feature, because we are not aware of any way to do that over Unix
sockets without a race condition; and if we can't have it securely, we
don't want to have it at all.
https://bugs.freedesktop.org/show_bug.cgi?id=83499
It would be great if kdbus can fix that omission.

Capabilities are in the same boat, and as a result, systemd can't
currently have D-Bus methods that can only be called with CAP_WHATEVER.

 * fewer userspace context switches
[...]
 * fewer message copies in userspace

Readers are probably already aware of this, but note that D-Bus is
designed to be usable between mutually distrusting processes, which is
why we use Unix sockets and a lot of copies, rather than mmap or something.

S

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 00/12] Add kdbus implementation

[Andy Lutomirski]

On Thu, Oct 30, 2014 at 3:15 AM, Tom Gundersen t...@jklm.no wrote:
 Do I understand you correctly that what you want is unnamed/anonymous
 domains? Considering that domain creation is anyway privileged, why is
 this necessary?

As an executive summary, this is the *problem*, not a mitigation.
Domain creation *should not require privilege*.  You should be able to
do it in a user namespace in which you have appropriate capabilities
without needing systemd's (or whatever other daemon's) help from
outside.

Once you fix that (which may not have broken whatever you tested with
but will absolutely break anyone who tries to use this in LXC, Docker,
Sandstorm, etc. without awful hacks) then you will have all of the
problems that you've currently mitigated.

--Andy
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 00/12] Add kdbus implementation

[Andy Lutomirski]

On Thu, Oct 30, 2014 at 4:52 AM, Tom Gundersen t...@jklm.no wrote:
 On 10/30/2014 12:55 AM, Andy Lutomirski wrote: It's worth noting that:

  - Proper credential passing could be added to UNIX sockets, and we
 may want to do that anyway.  Also, the current kdbus semantics seem to
 be spew lots of credentials and other miscellaneous
 potentially-sensitive and sometime spoofable information all over the
 place, which isn't obviously an improvement.  (This is fixable, but
 it will almost certainly not be compatible with current systemd kdbus
 code if fixed.)

 Care to elaborate on what you think is spoofable, and what needs to be fixed?

cmd and comm are trivially replaceable by any sender.


 Anyway, the idea is that by simply connecting to the bus and sending a
 message to some service, you implicitly agree to passing some metadata
 along to the service (and to a lesser extent to the bus). It's not
 that this information is leaked, or that the peer could actively
 access any of the sender's private memory.

To me, this smells like bad design.  By using kdbus, I implicitly
agree to send everyone my command line?!?  If I'm in a cgroup that
policy decrees should be privileged, then I should invoke that
privilege by specifically asking, *at the time of capture*, to send
that cgroup.  Otherwise it becomes unclear what things convey
privilege when, and that will lead immediately to incomprehensible
security models, and that will lead to exploits.

snarkSorry, but implicitly agree sounds a lot like using my
esteemed cellphone carrier.  When I use it, some argue that I
implicitly agree to have my identity prepended to all outgoing HTTP
requests.  This is *not* a good thing./snark

 Also note that this kind of
 metadata information is also available via /proc/$PID, and via
 SCM_CREDENTIALS/SO_PEERCRED and the socket seclabel APIs.

Not if you have a sensible LSM policy or if you use hidepid.  And,
once you've fixed the namespacing issues, not if the sender and
receiver are in different PID namespaces or if they don't have /proc
mounted at all.


 When credential information is passed between processes of different
 (PID) namespaces most of the attached metadata is suppressed.

This is a bug.  It prevents users from usefully sandboxing themselves
in a kdbus world.  If you create and enter a user namespace, then your
outside identity (which should be unchanged) is suppressed.  (Note
that anything that captures credentials other than at open time is
also an issue for sandboxes in the other direction: it may interfere
with selective privilege dropping.)

 This
 isn't too different from how SCM_CREDENTIALS works, which will zero
 out the bits it cannot translate as well.

SCM_CREDENTIALS translates the translatable parts.

 There are some major benefits regarding performance:

 * fewer userspace context switches. For a full-duplex method call it's
 down from five to two: instead of sender - dbus daemon - service -
 dbus daemon - sender it's just sender - service - sender.
 * fewer message copies in userspace. For a full-duplex method call
 it's down from eight to two: instead of copying the method call data
 into a socket, out of a socket, into a socket, out of a socket, and
 the same for the method reply, we just copy one message directly to
 the receiver, and the reply back.
 * generally fewer syscalls involved. A synchronous method call is now
 doable in a single ioctl on the sender side.
 * memfds can be used for transport purposes of larger payload. This
 way, we can cover substantial payload sizes instead of just small
 control messages, with no extra copies. kdbus, in its transport layer,
 makes sure only sealed memfds are passed in as payload, so the sender
 cannot modify the contents while the receiver is already parsing it.

There should be a number measured in, say, nanoseconds in here
somewhere.  The actual extent of the speedup is unmeasurable here.
Also, it's worth reading at least one of Linus' many rants about
zero-copy.  It's not an automatic win.

--Andy
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 00/12] Add kdbus implementation

[Greg Kroah-Hartman]

On Thu, Oct 30, 2014 at 11:44:39AM +0100, Karol Lewandowski wrote:
 [ Sorry for breaking thread and resend - gmane rejected my original message
   due to too long list of recipients... ]
 
 On 2014-10-30 00:40, Greg Kroah-Hartman wrote:
 
  There is a 1815 line documentation file in this series, so we aren't
  trying to not provide this type of information here at all.  But yes,
  more background, about why this can't be done in userspace (zero copy,
  less context switches, proper credential passing, timestamping, availble
  at early-boot, LSM hooks for security models to tie into
 
 While you're at it... I did some work on proof-of-concept LSM patches for
 kdbus some time ago, see [1][2].  Currently, these are completely of date.
 
  [1] https://github.com/lmctl/linux/commits/kdbus-lsm-v4.for-systemd-v212
  [2] 
 https://github.com/lmctl/kdbus/commit/aa0885489d19be92fa41c6f0a71df28763228a40
 
 May I ask if you guys have your own plan for LSM or maybe it would be
 worth to resurrect [1]?

The core calls are already mediated by LSM today, right?  We don't want
anyone to be parsing the data stream through an LSM, that idea got
rejected a long time ago as something that is really not a good idea.

Other than that, I don't know exactly what your patches do, or why they
are needed, care to go into details?

thanks,

greg k-h
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 00/12] Add kdbus implementation

[Greg Kroah-Hartman]

On Thu, Oct 30, 2014 at 09:33:56AM +0100, Arnd Bergmann wrote:
 On Wednesday 29 October 2014 15:00:44 Greg Kroah-Hartman wrote:
   drivers/misc/Kconfig |1 +
   drivers/misc/Makefile|1 +
   drivers/misc/kdbus/Kconfig   |   11 +
   drivers/misc/kdbus/Makefile  |   19 +
   drivers/misc/kdbus/bus.c |  450 ++
   drivers/misc/kdbus/bus.h |  107 ++
   drivers/misc/kdbus/connection.c  | 1751 
  +
   drivers/misc/kdbus/connection.h  |  177 +++
   drivers/misc/kdbus/domain.c  |  477 ++
  
 
 One very high-level common:
 
 Since this is going to be a very commonly used IPC mechanism, I don't
 like the idea of stuffing it into drivers/misc.
 
 How about putting it into drivers/kdbus or ipc/kdbus instead?

ipc/kdbus seems good to me.  I didn't want to pollute drivers/ with
any new subdirectories, it seems to grow fast enough as it is...

greg k-h
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 00/12] Add kdbus implementation

[Karol Lewandowski]

On 2014-10-30 15:47, Greg Kroah-Hartman wrote:
 On Thu, Oct 30, 2014 at 11:44:39AM +0100, Karol Lewandowski wrote:
 [ Sorry for breaking thread and resend - gmane rejected my original message
   due to too long list of recipients... ]

 On 2014-10-30 00:40, Greg Kroah-Hartman wrote:

 There is a 1815 line documentation file in this series, so we aren't
 trying to not provide this type of information here at all.  But yes,
 more background, about why this can't be done in userspace (zero copy,
 less context switches, proper credential passing, timestamping, availble
 at early-boot, LSM hooks for security models to tie into

 While you're at it... I did some work on proof-of-concept LSM patches for
 kdbus some time ago, see [1][2].  Currently, these are completely of date.

  [1] https://github.com/lmctl/linux/commits/kdbus-lsm-v4.for-systemd-v212
  [2] 
 https://github.com/lmctl/kdbus/commit/aa0885489d19be92fa41c6f0a71df28763228a40

 May I ask if you guys have your own plan for LSM or maybe it would be
 worth to resurrect [1]?
 
 The core calls are already mediated by LSM today, right?  We don't want
 anyone to be parsing the data stream through an LSM, that idea got
 rejected a long time ago as something that is really not a good idea.

Parsing data is out of question, of course, but this is not what we were
proposing.

 Other than that, I don't know exactly what your patches do, or why they
 are needed, care to go into details?

Patches in question were supposed to add few hooks for kdbus-specific
operations that doesn't seem to have compatible semantics with hooks
currently available in LSM.

kdbus' bus introduces quite a few new concepts that we wanted to be able
to limit based on MAC label/context, eg.

 - check flags at HELO stage (say disallow fd passing),

 - restrict ability to acquire name to certain subjects (for system bus),

 - disallow creation of new buses,

 - limit scope of broadcasts,

 - etc.

Please take a look at hook list - I think most of names are self-explanatory:

  
https://github.com/lmctl/linux/blob/a9fe4c33b6e5ab25a243e0590df406aabb6add12/include/linux/security.h#L1874

kdbus modifications were pretty light - with most visible change being
addition of opaque security pointer to kdbus_bus and similar structs.

Thanks!
-- 
Karol Lewandowski, Samsung RD Institute Poland
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 00/12] Add kdbus implementation

[Greg Kroah-Hartman]

On Thu, Oct 30, 2014 at 08:55:56PM +0100, Karol Lewandowski wrote:
 On 2014-10-30 15:47, Greg Kroah-Hartman wrote:
  On Thu, Oct 30, 2014 at 11:44:39AM +0100, Karol Lewandowski wrote:
  [ Sorry for breaking thread and resend - gmane rejected my original message
due to too long list of recipients... ]
 
  On 2014-10-30 00:40, Greg Kroah-Hartman wrote:
 
  There is a 1815 line documentation file in this series, so we aren't
  trying to not provide this type of information here at all.  But yes,
  more background, about why this can't be done in userspace (zero copy,
  less context switches, proper credential passing, timestamping, availble
  at early-boot, LSM hooks for security models to tie into
 
  While you're at it... I did some work on proof-of-concept LSM patches for
  kdbus some time ago, see [1][2].  Currently, these are completely of date.
 
   [1] https://github.com/lmctl/linux/commits/kdbus-lsm-v4.for-systemd-v212
   [2] 
  https://github.com/lmctl/kdbus/commit/aa0885489d19be92fa41c6f0a71df28763228a40
 
  May I ask if you guys have your own plan for LSM or maybe it would be
  worth to resurrect [1]?
  
  The core calls are already mediated by LSM today, right?  We don't want
  anyone to be parsing the data stream through an LSM, that idea got
  rejected a long time ago as something that is really not a good idea.
 
 Parsing data is out of question, of course, but this is not what we were
 proposing.

Glad to hear it :)

  Other than that, I don't know exactly what your patches do, or why they
  are needed, care to go into details?
 
 Patches in question were supposed to add few hooks for kdbus-specific
 operations that doesn't seem to have compatible semantics with hooks
 currently available in LSM.
 
 kdbus' bus introduces quite a few new concepts that we wanted to be able
 to limit based on MAC label/context, eg.
 
  - check flags at HELO stage (say disallow fd passing),
 
  - restrict ability to acquire name to certain subjects (for system bus),
 
  - disallow creation of new buses,
 
  - limit scope of broadcasts,
 
  - etc.

Nice list.

 Please take a look at hook list - I think most of names are self-explanatory:
 
   
 https://github.com/lmctl/linux/blob/a9fe4c33b6e5ab25a243e0590df406aabb6add12/include/linux/security.h#L1874
 
 kdbus modifications were pretty light - with most visible change being
 addition of opaque security pointer to kdbus_bus and similar structs.

That looks very reasonable, care to make it up into a patch I can add to
the end of this series so it's easy to review and possibly submit as
part of it?

thanks,

greg k-h
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 00/12] Add kdbus implementation

[Alex Elsayed]

Andy Lutomirski wrote:

snip
 There should be a number measured in, say, nanoseconds in here
 somewhere.  The actual extent of the speedup is unmeasurable here.
 Also, it's worth reading at least one of Linus' many rants about
 zero-copy.  It's not an automatic win.

It's well-understood that it's not an automatic win; significant testing on 
multiple architectures indicated that 512K is a surprisingly universal 
crossover point. The userspace code, therefore, switches from copying 
(normal kdbus parameters) to zero-copy (memfds) right around there.

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 00/12] Add kdbus implementation

[One Thousand Gnomes]

  The core calls are already mediated by LSM today, right?  We don't want
  anyone to be parsing the data stream through an LSM, that idea got
  rejected a long time ago as something that is really not a good idea.
 
 Parsing data is out of question, of course, but this is not what we were
 proposing.

Why is it out of the question. If it's a socket you can just a BPF filter
on it, so why can't kdbus support similar basic functionality ?

Alan
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 00/12] Add kdbus implementation

[Paul Moore]

On Thursday, October 30, 2014 08:55:56 PM Karol Lewandowski wrote:
 On 2014-10-30 15:47, Greg Kroah-Hartman wrote:
  Other than that, I don't know exactly what your patches do, or why they
  are needed, care to go into details?
 
 Patches in question were supposed to add few hooks for kdbus-specific
 operations that doesn't seem to have compatible semantics with hooks
 currently available in LSM.
 
 kdbus' bus introduces quite a few new concepts that we wanted to be able
 to limit based on MAC label/context, eg.
 
  - check flags at HELO stage (say disallow fd passing),
 
  - restrict ability to acquire name to certain subjects (for system bus),
 
  - disallow creation of new buses,
 
  - limit scope of broadcasts,
 
  - etc.
 
 Please take a look at hook list - I think most of names are
 self-explanatory:
 
  
 https://github.com/lmctl/linux/blob/a9fe4c33b6e5ab25a243e0590df406aabb6add1
 2/include/linux/security.h#L1874
 
 kdbus modifications were pretty light - with most visible change being
 addition of opaque security pointer to kdbus_bus and similar structs.

[NOTE: we really should add the LSM list to this discussion and future 
patchset postings.]

Also, to be completely honest, I don't think we ever really arrived at any 
final conclusion about those LSM/kdbus hooks either.  At least I don't think I 
ever really satisfied myself that what we had was the right solution.

We both got busy and kinda drifted away from this effort.  Karol, did you do 
any further work on the hooks?

-- 
paul moore
security and virtualization @ redhat

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 00/12] Add kdbus implementation

[Eric W. Biederman]

The userspace API breaks userspace in an unfixable way.

Nacked-by: "Eric W. Biederman" 

Problem the first.
- Using global names for containers makes it impossible to create
  unprivileged containers.

  This is a back to the drawing board problem, and makes device
  nodes fundamentally unsuited to what you are doing.

  There is no way that I can see to make it safe for an unprivileged
  user to create arbitrary named busses.  Especially in the presence
  of allowing unprivileged checkpoint/restart.

  This is particularly bad as kdbus explicitly allows unprivielged
  creation of new kdbus instances.

  This problem is a userspace regression.

Problem the second.
- The security checks in the code are not based on who opens the
  file descriptors but instead based on who is used the file
  descriptors at any give moment.

  That pattern has been shown to be exploitable.

  I expect the policy database makes this poor choice of permission
  checks even worse.  Pass a more privileged user a kdbus file
  descriptor and all of sudden things that were not possible on
  that file descriptor become possible.

Problem the third.
- You are using device numbers for things created by unprivileged
  users.  That breaks checkpoint/restart.  Aka CRIU.

  We can not migrate a container to a new machine and preserve the
  device numbers.  

  We can not migrate a container to a new machine and have any hope
  of preserving the container patsh under /dev/kdbus/...

  Both of which look like fundamental show stoppers for
  checkpoint/restart.

Andy Lutomirski  writes:

> On Wed, Oct 29, 2014 at 3:27 PM, Greg Kroah-Hartman
>  wrote:
>> On Wed, Oct 29, 2014 at 03:15:51PM -0700, Andy Lutomirski wrote:
>>> (reply 1/2 -- I'm replying twice to keep the threading sane)
>>>
>>> On Wed, Oct 29, 2014 at 3:00 PM, Greg Kroah-Hartman
>>>  wrote:
>>> > kdbus is a kernel-level IPC implementation that aims for resemblance to
>>> > the the protocol layer with the existing userspace D-Bus daemon while
>>> > enabling some features that couldn't be implemented before in userspace.
>>> >
>>>
>>> >  * Support for multiple domains, completely separated from each other,
>>> >allowing multiple virtualized instances to be used at the same time.
>>>
>>> Given that there is no such thing as a device namespace, how does this work?
>>
>> See the document for the details.
>
> They seem insufficient to me, so I tried to dig in to the code.  My
> understanding is:
>
> The parent container has /dev mounted.  It sends an IOCTL (which
> requires global capabilities).  In response, kdbus creates a whole
> bunch of devices that get put (by udev or devtmpfs, I presume) in a
> subdirectory.  Then the parent container mounts that subdirectory in
> the new container.
>
> This is IMO rather problematic.
>
> First, it enforces the existence of a kdbus domain hierarchy where
> none should be needed.
>
> Second, it's incompatible with nested user namespaces.  The middle
> namespace can't issue the ioctl.
>
> Third, it requires a devtmpfs submount in the child container.  This
> scares me, especially since there are no device namespaces.  Also, the
> child container appears to be dependent on the host udev to arbitrate
> everything, which seems totally wrong to me.  (Also, now we're exposed
> to attacks where the child container creates busses or endpoints or
> whatever with malicious names to try to trick the host into screwing
> up.)
>
> ISTM this should be solved either with device namespaces (which is
> well known to be a giant can of worms) or by abandoning the concept of
> kdbus using device nodes entirely.
>
> What if kdbus were kdbusfs?  If you want to use it in a container, you
> mount a brand-new kdbusfs there.  No weird domain hierarchy, no global
> privilege, no need to name containers, obvious migration semantics, no
> dependence on udev/devtmpfs at all, etc.
>
> Eric, any thoughts here?

I think a kdbusfs modeled on devpts with newinstance at
mount time would solve the naming problems.

That would break one of the current kdbus use cases that allows an
unprivileged user to create a bus.

Eric

p.s.  Please excuse my brevity I have am in the middle of packing up my
possessions (including my main machine), as I move this week.


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 00/12] Add kdbus implementation

[Eric W. Biederman]

Greg KH  writes:

> On Wed, Oct 29, 2014 at 03:00:44PM -0700, Greg Kroah-Hartman wrote:
>> kdbus is a kernel-level IPC implementation that aims for resemblance to
>> the the protocol layer with the existing userspace D-Bus daemon while
>> enabling some features that couldn't be implemented before in userspace.
>
> {sigh}
>
> I'll blame it on the jet-lag for the lack of [XX/12] markings on the
> patches.  I'll give it a day for review before resending if people
> really want to know the ordering.  It doesn't matter except for the
> final patch that adds the code to the build file.
>
> sorry about that,

For what it is worth these patches are also poorly split up.  Every
patch I looked at in detail had functions that were being introduced
that did not have callers.

That poor split up of the patches makes it difficult to see how
the functionality that is being introduced is being used.

Eric
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 00/12] Add kdbus implementation

[Andy Lutomirski]

On Wed, Oct 29, 2014 at 3:27 PM, Greg Kroah-Hartman
 wrote:
> On Wed, Oct 29, 2014 at 03:15:51PM -0700, Andy Lutomirski wrote:
>> (reply 1/2 -- I'm replying twice to keep the threading sane)
>>
>> On Wed, Oct 29, 2014 at 3:00 PM, Greg Kroah-Hartman
>>  wrote:
>> > kdbus is a kernel-level IPC implementation that aims for resemblance to
>> > the the protocol layer with the existing userspace D-Bus daemon while
>> > enabling some features that couldn't be implemented before in userspace.
>> >
>>
>> >  * Support for multiple domains, completely separated from each other,
>> >allowing multiple virtualized instances to be used at the same time.
>>
>> Given that there is no such thing as a device namespace, how does this work?
>
> See the document for the details.

They seem insufficient to me, so I tried to dig in to the code.  My
understanding is:

The parent container has /dev mounted.  It sends an IOCTL (which
requires global capabilities).  In response, kdbus creates a whole
bunch of devices that get put (by udev or devtmpfs, I presume) in a
subdirectory.  Then the parent container mounts that subdirectory in
the new container.

This is IMO rather problematic.

First, it enforces the existence of a kdbus domain hierarchy where
none should be needed.

Second, it's incompatible with nested user namespaces.  The middle
namespace can't issue the ioctl.

Third, it requires a devtmpfs submount in the child container.  This
scares me, especially since there are no device namespaces.  Also, the
child container appears to be dependent on the host udev to arbitrate
everything, which seems totally wrong to me.  (Also, now we're exposed
to attacks where the child container creates busses or endpoints or
whatever with malicious names to try to trick the host into screwing
up.)

ISTM this should be solved either with device namespaces (which is
well known to be a giant can of worms) or by abandoning the concept of
kdbus using device nodes entirely.

What if kdbus were kdbusfs?  If you want to use it in a container, you
mount a brand-new kdbusfs there.  No weird domain hierarchy, no global
privilege, no need to name containers, obvious migration semantics, no
dependence on udev/devtmpfs at all, etc.

Eric, any thoughts here?

--Andy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 00/12] Add kdbus implementation

[Andy Lutomirski]

On Wed, Oct 29, 2014 at 4:40 PM, Greg Kroah-Hartman
 wrote:
> On Thu, Oct 30, 2014 at 12:24:02AM +0100, Jiri Kosina wrote:
>> On Wed, 29 Oct 2014, Greg Kroah-Hartman wrote:
>>
>> > > > kdbus is a kernel-level IPC implementation that aims for resemblance to
>> > > > the the protocol layer with the existing userspace D-Bus daemon while
>> > > > enabling some features that couldn't be implemented before in 
>> > > > userspace.
>> > >
>> > > I'd be interested in the features that can't be implemented in userspace
>> > > (and therefore would justify existence of kdbus in the kernel). Could you
>> > > please point me to such list / documentation?
>> >
>> > Lennart has given whole talks about this in the past, here's a recent
>> > talk going into the details:
>> > https://www.youtube.com/watch?v=HPbQzm_iz_k
>>
>> I think it's a reasonable expectation that kernel patch submissions should
>> be reasonably self-contained though. We've always been very strict about
>> pushing everybody to provide extensive cover letters, changelogs and
>> explanations, so this shouldn't really be an exception, I think.
>
> There is a 1815 line documentation file in this series, so we aren't
> trying to not provide this type of information here at all.  But yes,
> more background, about why this can't be done in userspace (zero copy,
> less context switches, proper credential passing, timestamping, availble
> at early-boot, LSM hooks for security models to tie into, race-free
> interfaces, container/namespace support, etc.) should be added to the
> docs as well.

It's worth noting that:

 - Proper credential passing could be added to UNIX sockets, and we
may want to do that anyway.  Also, the current kdbus semantics seem to
be "spew lots of credentials and other miscellaneous
potentially-sensitive and sometime spoofable information all over the
place", which isn't obviously an improvement.  (This is fixable, but
it will almost certainly not be compatible with current systemd kdbus
code if fixed.)

 - The current kdbus patches seem to be worse than UNIX sockets from a
namespace perspective, but maybe I'm misunderstanding how it's
supposed to work.  UNIX sockets work quite nicely in containers.

 - There's an obvious interface to add timestamping to UNIX sockets
(it could work exactly the way it does for UDP / PTP).

 - I'm unconvinced by this performance argument without numbers.  The
kdbus credential code, at least, looks to be quite heavy on allocation
and atomics.  This isn't to say that the current userspace D-Bus
daemon doesn't also serialize everything, but it could be made
multithreaded.

 - Race-free?  What are the races that are inherent to UNIX sockets?

--Andy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 00/12] Add kdbus implementation

[Greg Kroah-Hartman]

On Thu, Oct 30, 2014 at 12:24:02AM +0100, Jiri Kosina wrote:
> On Wed, 29 Oct 2014, Greg Kroah-Hartman wrote:
> 
> > > > kdbus is a kernel-level IPC implementation that aims for resemblance to
> > > > the the protocol layer with the existing userspace D-Bus daemon while
> > > > enabling some features that couldn't be implemented before in userspace.
> > > 
> > > I'd be interested in the features that can't be implemented in userspace 
> > > (and therefore would justify existence of kdbus in the kernel). Could you 
> > > please point me to such list / documentation?
> > 
> > Lennart has given whole talks about this in the past, here's a recent
> > talk going into the details:
> > https://www.youtube.com/watch?v=HPbQzm_iz_k
> 
> I think it's a reasonable expectation that kernel patch submissions should 
> be reasonably self-contained though. We've always been very strict about 
> pushing everybody to provide extensive cover letters, changelogs and 
> explanations, so this shouldn't really be an exception, I think.

There is a 1815 line documentation file in this series, so we aren't
trying to not provide this type of information here at all.  But yes,
more background, about why this can't be done in userspace (zero copy,
less context switches, proper credential passing, timestamping, availble
at early-boot, LSM hooks for security models to tie into, race-free
interfaces, container/namespace support, etc.) should be added to the
docs as well.

> > > It seems to me that most of the highlight features from the cover letter 
> > > can be "easily" (for certain definition of that word, of course) 
> > > implemented in userspace (vmsplice(), sending fd through unix socket, 
> > > user 
> > > namespaces, UUID management, etc).
> > 
> > We have dbus in userspace today, but that requires extra copies of data,
> 
> But we can do zero-copy between processess for quite some time already, so 
> what exactly is the issue here?

See the above list for more details.

We'll work on this for the next round of patches, thanks.

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 00/12] Add kdbus implementation

[Greg Kroah-Hartman]

On Thu, Oct 30, 2014 at 12:26:33AM +0100, Jiri Kosina wrote:
> On Thu, 30 Oct 2014, Jiri Kosina wrote:
> 
> > > > It seems to me that most of the highlight features from the cover 
> > > > letter 
> > > > can be "easily" (for certain definition of that word, of course) 
> > > > implemented in userspace (vmsplice(), sending fd through unix socket, 
> > > > user 
> > > > namespaces, UUID management, etc).
> > > 
> > > We have dbus in userspace today, but that requires extra copies of data,
> > 
> > But we can do zero-copy between processess for quite some time already, so 
> > what exactly is the issue here?
> > 
> > > and isn't easy, or even possible, to do some of the application-specific
> > > bus logic that kdbus provides.  
> > 
> > I unfortunately have absolutely no idea what should I imagine here.
> 
> Also, I think I have heard that binder is going out of staging now, right?

Yes, but that needs documentation, which I'm working on at the moment :)

> I admittedly have very limited understanding of both binder and kdbus, but 
> I guess that is the case for many folks. My understanding is that they are 
> providing very similar functionality, so explanation why we need *both* in 
> the kernel would be very interesting as well.

They do very different things, see this writeup I did a while ago about
the differences between them:
http://kroah.com/log/blog/2014/01/15/kdbus-details/

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 00/12] Add kdbus implementation

[Jiri Kosina]

On Thu, 30 Oct 2014, Jiri Kosina wrote:

> > > It seems to me that most of the highlight features from the cover letter 
> > > can be "easily" (for certain definition of that word, of course) 
> > > implemented in userspace (vmsplice(), sending fd through unix socket, 
> > > user 
> > > namespaces, UUID management, etc).
> > 
> > We have dbus in userspace today, but that requires extra copies of data,
> 
> But we can do zero-copy between processess for quite some time already, so 
> what exactly is the issue here?
> 
> > and isn't easy, or even possible, to do some of the application-specific
> > bus logic that kdbus provides.  
> 
> I unfortunately have absolutely no idea what should I imagine here.

Also, I think I have heard that binder is going out of staging now, right?

I admittedly have very limited understanding of both binder and kdbus, but 
I guess that is the case for many folks. My understanding is that they are 
providing very similar functionality, so explanation why we need *both* in 
the kernel would be very interesting as well.

-- 
Jiri Kosina
SUSE Labs

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 00/12] Add kdbus implementation

[Jiri Kosina]

On Wed, 29 Oct 2014, Greg Kroah-Hartman wrote:

> > > kdbus is a kernel-level IPC implementation that aims for resemblance to
> > > the the protocol layer with the existing userspace D-Bus daemon while
> > > enabling some features that couldn't be implemented before in userspace.
> > 
> > I'd be interested in the features that can't be implemented in userspace 
> > (and therefore would justify existence of kdbus in the kernel). Could you 
> > please point me to such list / documentation?
> 
> Lennart has given whole talks about this in the past, here's a recent
> talk going into the details:
>   https://www.youtube.com/watch?v=HPbQzm_iz_k

I think it's a reasonable expectation that kernel patch submissions should 
be reasonably self-contained though. We've always been very strict about 
pushing everybody to provide extensive cover letters, changelogs and 
explanations, so this shouldn't really be an exception, I think.

> > It seems to me that most of the highlight features from the cover letter 
> > can be "easily" (for certain definition of that word, of course) 
> > implemented in userspace (vmsplice(), sending fd through unix socket, user 
> > namespaces, UUID management, etc).
> 
> We have dbus in userspace today, but that requires extra copies of data,

But we can do zero-copy between processess for quite some time already, so 
what exactly is the issue here?

> and isn't easy, or even possible, to do some of the application-specific
> bus logic that kdbus provides.  

I unfortunately have absolutely no idea what should I imagine here.

> See the talk above for details, there are slides around somewhere with 
> just text that we can add to the cover letter if that will help out in 
> future spins of this patch series.

I think that would be very helpful. Thanks.

-- 
Jiri Kosina
SUSE Labs

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 00/12] Add kdbus implementation

[Greg Kroah-Hartman]

On Wed, Oct 29, 2014 at 04:11:06PM -0700, Greg Kroah-Hartman wrote:
> On Thu, Oct 30, 2014 at 12:00:16AM +0100, Jiri Kosina wrote:
> > On Wed, 29 Oct 2014, Greg Kroah-Hartman wrote:
> > 
> > > kdbus is a kernel-level IPC implementation that aims for resemblance to
> > > the the protocol layer with the existing userspace D-Bus daemon while
> > > enabling some features that couldn't be implemented before in userspace.
> > 
> > I'd be interested in the features that can't be implemented in userspace 
> > (and therefore would justify existence of kdbus in the kernel). Could you 
> > please point me to such list / documentation?
> 
> Lennart has given whole talks about this in the past, here's a recent
> talk going into the details:
>   https://www.youtube.com/watch?v=HPbQzm_iz_k
> 
> > It seems to me that most of the highlight features from the cover letter 
> > can be "easily" (for certain definition of that word, of course) 
> > implemented in userspace (vmsplice(), sending fd through unix socket, user 
> > namespaces, UUID management, etc).
> 
> We have dbus in userspace today, but that requires extra copies of data,
> and isn't easy, or even possible, to do some of the application-specific
> bus logic that kdbus provides.  See the talk above for details, there
> are slides around somewhere with just text that we can add to the cover
> letter if that will help out in future spins of this patch series.

Here's an article describing it as well:
https://lwn.net/Articles/580194/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 00/12] Add kdbus implementation

[Greg Kroah-Hartman]

On Thu, Oct 30, 2014 at 12:00:16AM +0100, Jiri Kosina wrote:
> On Wed, 29 Oct 2014, Greg Kroah-Hartman wrote:
> 
> > kdbus is a kernel-level IPC implementation that aims for resemblance to
> > the the protocol layer with the existing userspace D-Bus daemon while
> > enabling some features that couldn't be implemented before in userspace.
> 
> I'd be interested in the features that can't be implemented in userspace 
> (and therefore would justify existence of kdbus in the kernel). Could you 
> please point me to such list / documentation?

Lennart has given whole talks about this in the past, here's a recent
talk going into the details:
https://www.youtube.com/watch?v=HPbQzm_iz_k

> It seems to me that most of the highlight features from the cover letter 
> can be "easily" (for certain definition of that word, of course) 
> implemented in userspace (vmsplice(), sending fd through unix socket, user 
> namespaces, UUID management, etc).

We have dbus in userspace today, but that requires extra copies of data,
and isn't easy, or even possible, to do some of the application-specific
bus logic that kdbus provides.  See the talk above for details, there
are slides around somewhere with just text that we can add to the cover
letter if that will help out in future spins of this patch series.

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 00/12] Add kdbus implementation

[Jiri Kosina]

On Wed, 29 Oct 2014, Greg Kroah-Hartman wrote:

> kdbus is a kernel-level IPC implementation that aims for resemblance to
> the the protocol layer with the existing userspace D-Bus daemon while
> enabling some features that couldn't be implemented before in userspace.

I'd be interested in the features that can't be implemented in userspace 
(and therefore would justify existence of kdbus in the kernel). Could you 
please point me to such list / documentation?

It seems to me that most of the highlight features from the cover letter 
can be "easily" (for certain definition of that word, of course) 
implemented in userspace (vmsplice(), sending fd through unix socket, user 
namespaces, UUID management, etc).

Thanks,

-- 
Jiri Kosina
SUSE Labs

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 00/12] Add kdbus implementation

[Andy Lutomirski]

On Wed, Oct 29, 2014 at 3:28 PM, Andy Lutomirski  wrote:
> On Wed, Oct 29, 2014 at 3:25 PM, Greg Kroah-Hartman
>  wrote:
>> On Wed, Oct 29, 2014 at 03:19:21PM -0700, Andy Lutomirski wrote:
>>> On Wed, Oct 29, 2014 at 3:00 PM, Greg Kroah-Hartman
>>>  wrote:
>>> >  * Attachment of trustable metadata to each message on demand, such as
>>> >the sending peer's timestamp, creds, auxgroups, comm, exe, cmdline,
>>> >cgroup path, capabilities, security label, audit information, etc,
>>> >each taken at the time the sender issued the ioctl to send the
>>> >message. Which of those are actually recorded and attached is
>>> >controlled by the receiving peer.
>>>
>>> I think that each piece of trustable metadata needs to be explicitly
>>> opted-in to by the sender at the time of capture.  Otherwise you're
>>> asking for lots of information leaks and privilege escalations.  This
>>> is especially important given that some of the items in the current
>>> list could be rather sensitive.
>>
>> You do have to opt-in for this information at time of capture, so I
>> don't understand the issue here.  This is the same type of thing that
>> dbus does today, and I don't see the information leaks happening there,
>> do you?
>>
>
> The docs suggest that the *receiver* opts in.
>

So does the code:

+ /*
+ * The first receiver which requests additional
+ * metadata causes the message to carry it; all
+ * receivers after that will see all of the added
+ * data, even when they did not ask for it.
+ */
+ if (conn_src) {
+ /* Check if conn_src is allowed to signal */
+ ret = kdbus_ep_policy_check_broadcast(conn_dst->ep,
+ conn_src,
+ conn_dst);
+ if (ret < 0)
+ continue;
+
+ ret = kdbus_ep_policy_check_src_names(conn_dst->ep,
+ conn_src,
+ conn_dst);
+ if (ret < 0)
+ continue;
+
+ ret = kdbus_kmsg_attach_metadata(kmsg, conn_src,
+ conn_dst);
+ if (ret < 0)
+ goto exit_unlock;
+ }
+

I'd like this if the sender chose the metadata flags.  In fact, I'd
want to make that feature available on regular UNIX sockets, too
(search the archives for SCM_IDENTITY).

--Andy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 00/12] Add kdbus implementation

[Andy Lutomirski]

On Wed, Oct 29, 2014 at 3:27 PM, Greg Kroah-Hartman
 wrote:
> On Wed, Oct 29, 2014 at 03:15:51PM -0700, Andy Lutomirski wrote:
>> (reply 1/2 -- I'm replying twice to keep the threading sane)
>>
>> On Wed, Oct 29, 2014 at 3:00 PM, Greg Kroah-Hartman
>>  wrote:
>> > kdbus is a kernel-level IPC implementation that aims for resemblance to
>> > the the protocol layer with the existing userspace D-Bus daemon while
>> > enabling some features that couldn't be implemented before in userspace.
>> >
>>
>> >  * Support for multiple domains, completely separated from each other,
>> >allowing multiple virtualized instances to be used at the same time.
>>
>> Given that there is no such thing as a device namespace, how does this work?
>
> See the document for the details.
>
>> The docs seem a bit confusing to me as to whether there's a hierarchy
>> of domains.  Do domains have a concept of a parent?
>
> Yes.

Why?  Aren't they completely isolated?  Confused.

>
>> What's "container-name"?
>
> Is that used in the documentation?

/dev/kdbus/domain//+ directory shows up inside the
domain as /dev/kdbus/.

I guess that's the thing that the creator requests.

--Andy

>
>> Given that domains have random IDs, how can they be checkpointed and 
>> restored?
>
> Good question, I don't know about checkpoint/restore, but I think that
> has been done.  Daniel would know more than I do about that.
>
> thanks,
>
> greg k-h



-- 
Andy Lutomirski
AMA Capital Management, LLC
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 00/12] Add kdbus implementation

[Andy Lutomirski]

On Wed, Oct 29, 2014 at 3:25 PM, Greg Kroah-Hartman
 wrote:
> On Wed, Oct 29, 2014 at 03:19:21PM -0700, Andy Lutomirski wrote:
>> On Wed, Oct 29, 2014 at 3:00 PM, Greg Kroah-Hartman
>>  wrote:
>> >  * Attachment of trustable metadata to each message on demand, such as
>> >the sending peer's timestamp, creds, auxgroups, comm, exe, cmdline,
>> >cgroup path, capabilities, security label, audit information, etc,
>> >each taken at the time the sender issued the ioctl to send the
>> >message. Which of those are actually recorded and attached is
>> >controlled by the receiving peer.
>>
>> I think that each piece of trustable metadata needs to be explicitly
>> opted-in to by the sender at the time of capture.  Otherwise you're
>> asking for lots of information leaks and privilege escalations.  This
>> is especially important given that some of the items in the current
>> list could be rather sensitive.
>
> You do have to opt-in for this information at time of capture, so I
> don't understand the issue here.  This is the same type of thing that
> dbus does today, and I don't see the information leaks happening there,
> do you?
>

The docs suggest that the *receiver* opts in.

I don't think that current dbus has severe information leaks because
the total scope for information transparently sent to dbus is rather
small (struct ucred only, presumably).

--Andy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 00/12] Add kdbus implementation

[Greg Kroah-Hartman]

On Wed, Oct 29, 2014 at 03:15:51PM -0700, Andy Lutomirski wrote:
> (reply 1/2 -- I'm replying twice to keep the threading sane)
> 
> On Wed, Oct 29, 2014 at 3:00 PM, Greg Kroah-Hartman
>  wrote:
> > kdbus is a kernel-level IPC implementation that aims for resemblance to
> > the the protocol layer with the existing userspace D-Bus daemon while
> > enabling some features that couldn't be implemented before in userspace.
> >
> 
> >  * Support for multiple domains, completely separated from each other,
> >allowing multiple virtualized instances to be used at the same time.
> 
> Given that there is no such thing as a device namespace, how does this work?

See the document for the details.

> The docs seem a bit confusing to me as to whether there's a hierarchy
> of domains.  Do domains have a concept of a parent?

Yes.

> What's "container-name"?

Is that used in the documentation?

> Given that domains have random IDs, how can they be checkpointed and restored?

Good question, I don't know about checkpoint/restore, but I think that
has been done.  Daniel would know more than I do about that.

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 00/12] Add kdbus implementation

[Greg Kroah-Hartman]

On Wed, Oct 29, 2014 at 03:19:21PM -0700, Andy Lutomirski wrote:
> On Wed, Oct 29, 2014 at 3:00 PM, Greg Kroah-Hartman
>  wrote:
> >  * Attachment of trustable metadata to each message on demand, such as
> >the sending peer's timestamp, creds, auxgroups, comm, exe, cmdline,
> >cgroup path, capabilities, security label, audit information, etc,
> >each taken at the time the sender issued the ioctl to send the
> >message. Which of those are actually recorded and attached is
> >controlled by the receiving peer.
> 
> I think that each piece of trustable metadata needs to be explicitly
> opted-in to by the sender at the time of capture.  Otherwise you're
> asking for lots of information leaks and privilege escalations.  This
> is especially important given that some of the items in the current
> list could be rather sensitive.

You do have to opt-in for this information at time of capture, so I
don't understand the issue here.  This is the same type of thing that
dbus does today, and I don't see the information leaks happening there,
do you?

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 00/12] Add kdbus implementation

[Andy Lutomirski]

On Wed, Oct 29, 2014 at 3:00 PM, Greg Kroah-Hartman
 wrote:
>  * Attachment of trustable metadata to each message on demand, such as
>the sending peer's timestamp, creds, auxgroups, comm, exe, cmdline,
>cgroup path, capabilities, security label, audit information, etc,
>each taken at the time the sender issued the ioctl to send the
>message. Which of those are actually recorded and attached is
>controlled by the receiving peer.

I think that each piece of trustable metadata needs to be explicitly
opted-in to by the sender at the time of capture.  Otherwise you're
asking for lots of information leaks and privilege escalations.  This
is especially important given that some of the items in the current
list could be rather sensitive.

NB: UNIX sockets get this wrong, too, but that doesn't mean that kdbus
gets to blindly follow SCM_CREDENTIALS's lead.  Also, there is no
excuse here about legacy code that won't opt in when needed.

--Andy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 00/12] Add kdbus implementation

[Greg KH]

On Wed, Oct 29, 2014 at 03:00:44PM -0700, Greg Kroah-Hartman wrote:
> kdbus is a kernel-level IPC implementation that aims for resemblance to
> the the protocol layer with the existing userspace D-Bus daemon while
> enabling some features that couldn't be implemented before in userspace.

{sigh}

I'll blame it on the jet-lag for the lack of [XX/12] markings on the
patches.  I'll give it a day for review before resending if people
really want to know the ordering.  It doesn't matter except for the
final patch that adds the code to the build file.

sorry about that,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 00/12] Add kdbus implementation

[Andy Lutomirski]

(reply 1/2 -- I'm replying twice to keep the threading sane)

On Wed, Oct 29, 2014 at 3:00 PM, Greg Kroah-Hartman
 wrote:
> kdbus is a kernel-level IPC implementation that aims for resemblance to
> the the protocol layer with the existing userspace D-Bus daemon while
> enabling some features that couldn't be implemented before in userspace.
>

>  * Support for multiple domains, completely separated from each other,
>allowing multiple virtualized instances to be used at the same time.

Given that there is no such thing as a device namespace, how does this work?

The docs seem a bit confusing to me as to whether there's a hierarchy
of domains.  Do domains have a concept of a parent?

What's "container-name"?

Given that domains have random IDs, how can they be checkpointed and restored?

--Andy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 00/12] Add kdbus implementation

[Greg Kroah-Hartman]

kdbus is a kernel-level IPC implementation that aims for resemblance to
the the protocol layer with the existing userspace D-Bus daemon while
enabling some features that couldn't be implemented before in userspace.

The documentation added by the first patch in this series is meant to
explain all protocol and API details comprehensively, but here's a terse
list of the kdbus key features:

 * Implemented as a char driver, which creates devices on demand when
   they are created.

 * Message transfer over shared memory areas in each of the peer's
   task to avoid unnecessary extra data copies during message exchanges.

 * Optional passing of file descriptors and sealed memfds along with
   messages.

 * No demarshalling of any message content from inside the kernel;
   the driver stays entirely agnostic to the transported payload.

 * Support for multiple domains, completely separated from each other,
   allowing multiple virtualized instances to be used at the same time.

 * Support for peer-to-peer unicast and multicast messages.

 * Attachment of trustable metadata to each message on demand, such as
   the sending peer's timestamp, creds, auxgroups, comm, exe, cmdline,
   cgroup path, capabilities, security label, audit information, etc,
   each taken at the time the sender issued the ioctl to send the
   message. Which of those are actually recorded and attached is
   controlled by the receiving peer.

 * Bloom filters as measure to pre-filter broadcast messages and to
   mitigate unnecessary task wakeups. On the side kernel, however, this
   is just a cheap &-operation, hash functions are left to be
   implemented by userspace.

 * Optional message dequeuing by priority, allowing multiple types of
   payloads of different priorities to be transported over the same
   connection.

 * Global, domain-wide guaranteed message ordering.

 * Eavesdropping for buses for debugging

 * Adressing of remote peers by their numerical unique ID, or by a
   well-known name.

 * Built-in name registry for atomic name ownership lookups, claims,
   releases and take-overs from one peer to another.

 * Simple policy database to restrict peers from seeing or talking to
   each other, and to control name ownership.

 * Custom bus endpoints in addition to the default ones. Those allow
   to upload extra policy rules, and can act as a protocol-filtering
   bus firewall.

 * Kernel-generated notifications on connected and disconnected peers,
   claimed and released well-known-names, and exceeded reply timeouts.

This is the first submission of kdbus by the kernel community.  It was
developed in its own repository for well more than a year, and has been
tested on x64-64, i686 and ARM architectures in various use cases. The
driver is totally non-intrusive and doesn't touch a single line of
existing kernel code.

kdbus has been worked on collaboratively by many people contributing
code and suggestions during its development. Below is a list of all
involved individuals, in alphabetical order.

  Alban Crequy, Arnd Bergmann, Christian S., Daniel Kowalski,
  Daniel Mack, David Herrmann, Djalal Harouni, Govindarajulu
  Varadarajan, Greg Kroah-Hartman, Harald Hoyer, Hristo Venev,
  Ingo van Lil, Jacek Janczyk, Jason A. Donenfeld, John de
  la Garza, Kay Sievers, Lennart Poettering, Lukasz Skalski,
  Maciej Wereski, Marc-Antoine Perennou, Marcel Holtmann,
  Michal Eljasiewicz, Michele Curti, Przemyslaw Kedzierski,
  Radoslaw Pajak, Ryan Lortie, Simon McVittie, Simon Peeters,
  Stefan Beller, Ted Feng, Tejun Heo, Tero Roponen, Thomas
  Andersen, Torstein Husebø, Vasiliy Balyasnyy.

Some statistics: the driver itself has a little more than 11k lines,
with ~25% of the lines being comments. Our test suite weights in for
another 6k lines, and the API documentation file currently has >1800
lines. The loaded kernel module has ~70kB of text size.

Patches #3 to #10 carry the driver implementation in digestable bites,
but only #11 adds the Makefile to actually compile them. That division
can of course be changed, and the patches be squashed and reordered
later.

The rest should be pretty much self-explanatory - the individual commit
logs and Documentation/kdbus.txt contain detailed information on the
driver's inner life.

While we consider the kernel API/ABI mostly stable at this point, we're
still in the process of fixing up some ends in userspace, such as
compatibility layers and the D-Bus spec, but that shouldn't affect the
kernel side much anymore.

As for maintainership, Daniel Mack, David Herrmann, Djalal Harouni and
myself would be taking care for it in the future.

I'll also be keeping this in a git tree, the kdbus branch of
char-misc.git at:
https://git.kernel.org/cgit/linux/kernel/git/gregkh/char-misc.git/

thanks,

greg k-h

Daniel Mack (12):
  kdbus: add documentation
  kdbus: add header file
  kdbus: add driver skeleton, ioctl entry points and utility functions
  kdbus: add connection pool implementation
  kdbus: add 

[PATCH 00/12] Add kdbus implementation

[Greg Kroah-Hartman]

kdbus is a kernel-level IPC implementation that aims for resemblance to
the the protocol layer with the existing userspace D-Bus daemon while
enabling some features that couldn't be implemented before in userspace.

The documentation added by the first patch in this series is meant to
explain all protocol and API details comprehensively, but here's a terse
list of the kdbus key features:

 * Implemented as a char driver, which creates devices on demand when
   they are created.

 * Message transfer over shared memory areas in each of the peer's
   task to avoid unnecessary extra data copies during message exchanges.

 * Optional passing of file descriptors and sealed memfds along with
   messages.

 * No demarshalling of any message content from inside the kernel;
   the driver stays entirely agnostic to the transported payload.

 * Support for multiple domains, completely separated from each other,
   allowing multiple virtualized instances to be used at the same time.

 * Support for peer-to-peer unicast and multicast messages.

 * Attachment of trustable metadata to each message on demand, such as
   the sending peer's timestamp, creds, auxgroups, comm, exe, cmdline,
   cgroup path, capabilities, security label, audit information, etc,
   each taken at the time the sender issued the ioctl to send the
   message. Which of those are actually recorded and attached is
   controlled by the receiving peer.

 * Bloom filters as measure to pre-filter broadcast messages and to
   mitigate unnecessary task wakeups. On the side kernel, however, this
   is just a cheap -operation, hash functions are left to be
   implemented by userspace.

 * Optional message dequeuing by priority, allowing multiple types of
   payloads of different priorities to be transported over the same
   connection.

 * Global, domain-wide guaranteed message ordering.

 * Eavesdropping for buses for debugging

 * Adressing of remote peers by their numerical unique ID, or by a
   well-known name.

 * Built-in name registry for atomic name ownership lookups, claims,
   releases and take-overs from one peer to another.

 * Simple policy database to restrict peers from seeing or talking to
   each other, and to control name ownership.

 * Custom bus endpoints in addition to the default ones. Those allow
   to upload extra policy rules, and can act as a protocol-filtering
   bus firewall.

 * Kernel-generated notifications on connected and disconnected peers,
   claimed and released well-known-names, and exceeded reply timeouts.

This is the first submission of kdbus by the kernel community.  It was
developed in its own repository for well more than a year, and has been
tested on x64-64, i686 and ARM architectures in various use cases. The
driver is totally non-intrusive and doesn't touch a single line of
existing kernel code.

kdbus has been worked on collaboratively by many people contributing
code and suggestions during its development. Below is a list of all
involved individuals, in alphabetical order.

  Alban Crequy, Arnd Bergmann, Christian S., Daniel Kowalski,
  Daniel Mack, David Herrmann, Djalal Harouni, Govindarajulu
  Varadarajan, Greg Kroah-Hartman, Harald Hoyer, Hristo Venev,
  Ingo van Lil, Jacek Janczyk, Jason A. Donenfeld, John de
  la Garza, Kay Sievers, Lennart Poettering, Lukasz Skalski,
  Maciej Wereski, Marc-Antoine Perennou, Marcel Holtmann,
  Michal Eljasiewicz, Michele Curti, Przemyslaw Kedzierski,
  Radoslaw Pajak, Ryan Lortie, Simon McVittie, Simon Peeters,
  Stefan Beller, Ted Feng, Tejun Heo, Tero Roponen, Thomas
  Andersen, Torstein Husebø, Vasiliy Balyasnyy.

Some statistics: the driver itself has a little more than 11k lines,
with ~25% of the lines being comments. Our test suite weights in for
another 6k lines, and the API documentation file currently has 1800
lines. The loaded kernel module has ~70kB of text size.

Patches #3 to #10 carry the driver implementation in digestable bites,
but only #11 adds the Makefile to actually compile them. That division
can of course be changed, and the patches be squashed and reordered
later.

The rest should be pretty much self-explanatory - the individual commit
logs and Documentation/kdbus.txt contain detailed information on the
driver's inner life.

While we consider the kernel API/ABI mostly stable at this point, we're
still in the process of fixing up some ends in userspace, such as
compatibility layers and the D-Bus spec, but that shouldn't affect the
kernel side much anymore.

As for maintainership, Daniel Mack, David Herrmann, Djalal Harouni and
myself would be taking care for it in the future.

I'll also be keeping this in a git tree, the kdbus branch of
char-misc.git at:
https://git.kernel.org/cgit/linux/kernel/git/gregkh/char-misc.git/

thanks,

greg k-h

Daniel Mack (12):
  kdbus: add documentation
  kdbus: add header file
  kdbus: add driver skeleton, ioctl entry points and utility functions
  kdbus: add connection pool implementation
  kdbus: add 

Re: [PATCH 00/12] Add kdbus implementation

[Andy Lutomirski]

(reply 1/2 -- I'm replying twice to keep the threading sane)

On Wed, Oct 29, 2014 at 3:00 PM, Greg Kroah-Hartman
gre...@linuxfoundation.org wrote:
 kdbus is a kernel-level IPC implementation that aims for resemblance to
 the the protocol layer with the existing userspace D-Bus daemon while
 enabling some features that couldn't be implemented before in userspace.


  * Support for multiple domains, completely separated from each other,
allowing multiple virtualized instances to be used at the same time.

Given that there is no such thing as a device namespace, how does this work?

The docs seem a bit confusing to me as to whether there's a hierarchy
of domains.  Do domains have a concept of a parent?

What's container-name?

Given that domains have random IDs, how can they be checkpointed and restored?

--Andy
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 00/12] Add kdbus implementation

[Greg KH]

On Wed, Oct 29, 2014 at 03:00:44PM -0700, Greg Kroah-Hartman wrote:
 kdbus is a kernel-level IPC implementation that aims for resemblance to
 the the protocol layer with the existing userspace D-Bus daemon while
 enabling some features that couldn't be implemented before in userspace.

{sigh}

I'll blame it on the jet-lag for the lack of [XX/12] markings on the
patches.  I'll give it a day for review before resending if people
really want to know the ordering.  It doesn't matter except for the
final patch that adds the code to the build file.

sorry about that,

greg k-h
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 00/12] Add kdbus implementation

[Andy Lutomirski]

On Wed, Oct 29, 2014 at 3:00 PM, Greg Kroah-Hartman
gre...@linuxfoundation.org wrote:
  * Attachment of trustable metadata to each message on demand, such as
the sending peer's timestamp, creds, auxgroups, comm, exe, cmdline,
cgroup path, capabilities, security label, audit information, etc,
each taken at the time the sender issued the ioctl to send the
message. Which of those are actually recorded and attached is
controlled by the receiving peer.

I think that each piece of trustable metadata needs to be explicitly
opted-in to by the sender at the time of capture.  Otherwise you're
asking for lots of information leaks and privilege escalations.  This
is especially important given that some of the items in the current
list could be rather sensitive.

NB: UNIX sockets get this wrong, too, but that doesn't mean that kdbus
gets to blindly follow SCM_CREDENTIALS's lead.  Also, there is no
excuse here about legacy code that won't opt in when needed.

--Andy
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 00/12] Add kdbus implementation

[Greg Kroah-Hartman]

On Wed, Oct 29, 2014 at 03:19:21PM -0700, Andy Lutomirski wrote:
 On Wed, Oct 29, 2014 at 3:00 PM, Greg Kroah-Hartman
 gre...@linuxfoundation.org wrote:
   * Attachment of trustable metadata to each message on demand, such as
 the sending peer's timestamp, creds, auxgroups, comm, exe, cmdline,
 cgroup path, capabilities, security label, audit information, etc,
 each taken at the time the sender issued the ioctl to send the
 message. Which of those are actually recorded and attached is
 controlled by the receiving peer.
 
 I think that each piece of trustable metadata needs to be explicitly
 opted-in to by the sender at the time of capture.  Otherwise you're
 asking for lots of information leaks and privilege escalations.  This
 is especially important given that some of the items in the current
 list could be rather sensitive.

You do have to opt-in for this information at time of capture, so I
don't understand the issue here.  This is the same type of thing that
dbus does today, and I don't see the information leaks happening there,
do you?

thanks,

greg k-h
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 00/12] Add kdbus implementation

[Greg Kroah-Hartman]

On Wed, Oct 29, 2014 at 03:15:51PM -0700, Andy Lutomirski wrote:
 (reply 1/2 -- I'm replying twice to keep the threading sane)
 
 On Wed, Oct 29, 2014 at 3:00 PM, Greg Kroah-Hartman
 gre...@linuxfoundation.org wrote:
  kdbus is a kernel-level IPC implementation that aims for resemblance to
  the the protocol layer with the existing userspace D-Bus daemon while
  enabling some features that couldn't be implemented before in userspace.
 
 
   * Support for multiple domains, completely separated from each other,
 allowing multiple virtualized instances to be used at the same time.
 
 Given that there is no such thing as a device namespace, how does this work?

See the document for the details.

 The docs seem a bit confusing to me as to whether there's a hierarchy
 of domains.  Do domains have a concept of a parent?

Yes.

 What's container-name?

Is that used in the documentation?

 Given that domains have random IDs, how can they be checkpointed and restored?

Good question, I don't know about checkpoint/restore, but I think that
has been done.  Daniel would know more than I do about that.

thanks,

greg k-h
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 00/12] Add kdbus implementation

[Andy Lutomirski]

On Wed, Oct 29, 2014 at 3:25 PM, Greg Kroah-Hartman
gre...@linuxfoundation.org wrote:
 On Wed, Oct 29, 2014 at 03:19:21PM -0700, Andy Lutomirski wrote:
 On Wed, Oct 29, 2014 at 3:00 PM, Greg Kroah-Hartman
 gre...@linuxfoundation.org wrote:
   * Attachment of trustable metadata to each message on demand, such as
 the sending peer's timestamp, creds, auxgroups, comm, exe, cmdline,
 cgroup path, capabilities, security label, audit information, etc,
 each taken at the time the sender issued the ioctl to send the
 message. Which of those are actually recorded and attached is
 controlled by the receiving peer.

 I think that each piece of trustable metadata needs to be explicitly
 opted-in to by the sender at the time of capture.  Otherwise you're
 asking for lots of information leaks and privilege escalations.  This
 is especially important given that some of the items in the current
 list could be rather sensitive.

 You do have to opt-in for this information at time of capture, so I
 don't understand the issue here.  This is the same type of thing that
 dbus does today, and I don't see the information leaks happening there,
 do you?


The docs suggest that the *receiver* opts in.

I don't think that current dbus has severe information leaks because
the total scope for information transparently sent to dbus is rather
small (struct ucred only, presumably).

--Andy
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 00/12] Add kdbus implementation

[Andy Lutomirski]

On Wed, Oct 29, 2014 at 3:27 PM, Greg Kroah-Hartman
gre...@linuxfoundation.org wrote:
 On Wed, Oct 29, 2014 at 03:15:51PM -0700, Andy Lutomirski wrote:
 (reply 1/2 -- I'm replying twice to keep the threading sane)

 On Wed, Oct 29, 2014 at 3:00 PM, Greg Kroah-Hartman
 gre...@linuxfoundation.org wrote:
  kdbus is a kernel-level IPC implementation that aims for resemblance to
  the the protocol layer with the existing userspace D-Bus daemon while
  enabling some features that couldn't be implemented before in userspace.
 

   * Support for multiple domains, completely separated from each other,
 allowing multiple virtualized instances to be used at the same time.

 Given that there is no such thing as a device namespace, how does this work?

 See the document for the details.

 The docs seem a bit confusing to me as to whether there's a hierarchy
 of domains.  Do domains have a concept of a parent?

 Yes.

Why?  Aren't they completely isolated?  Confused.


 What's container-name?

 Is that used in the documentation?

/dev/kdbus/domain/container-name/+ directory shows up inside the
domain as /dev/kdbus/.

I guess that's the thing that the creator requests.

--Andy


 Given that domains have random IDs, how can they be checkpointed and 
 restored?

 Good question, I don't know about checkpoint/restore, but I think that
 has been done.  Daniel would know more than I do about that.

 thanks,

 greg k-h



-- 
Andy Lutomirski
AMA Capital Management, LLC
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 00/12] Add kdbus implementation

[Andy Lutomirski]

On Wed, Oct 29, 2014 at 3:28 PM, Andy Lutomirski l...@amacapital.net wrote:
 On Wed, Oct 29, 2014 at 3:25 PM, Greg Kroah-Hartman
 gre...@linuxfoundation.org wrote:
 On Wed, Oct 29, 2014 at 03:19:21PM -0700, Andy Lutomirski wrote:
 On Wed, Oct 29, 2014 at 3:00 PM, Greg Kroah-Hartman
 gre...@linuxfoundation.org wrote:
   * Attachment of trustable metadata to each message on demand, such as
 the sending peer's timestamp, creds, auxgroups, comm, exe, cmdline,
 cgroup path, capabilities, security label, audit information, etc,
 each taken at the time the sender issued the ioctl to send the
 message. Which of those are actually recorded and attached is
 controlled by the receiving peer.

 I think that each piece of trustable metadata needs to be explicitly
 opted-in to by the sender at the time of capture.  Otherwise you're
 asking for lots of information leaks and privilege escalations.  This
 is especially important given that some of the items in the current
 list could be rather sensitive.

 You do have to opt-in for this information at time of capture, so I
 don't understand the issue here.  This is the same type of thing that
 dbus does today, and I don't see the information leaks happening there,
 do you?


 The docs suggest that the *receiver* opts in.


So does the code:

+ /*
+ * The first receiver which requests additional
+ * metadata causes the message to carry it; all
+ * receivers after that will see all of the added
+ * data, even when they did not ask for it.
+ */
+ if (conn_src) {
+ /* Check if conn_src is allowed to signal */
+ ret = kdbus_ep_policy_check_broadcast(conn_dst-ep,
+ conn_src,
+ conn_dst);
+ if (ret  0)
+ continue;
+
+ ret = kdbus_ep_policy_check_src_names(conn_dst-ep,
+ conn_src,
+ conn_dst);
+ if (ret  0)
+ continue;
+
+ ret = kdbus_kmsg_attach_metadata(kmsg, conn_src,
+ conn_dst);
+ if (ret  0)
+ goto exit_unlock;
+ }
+

I'd like this if the sender chose the metadata flags.  In fact, I'd
want to make that feature available on regular UNIX sockets, too
(search the archives for SCM_IDENTITY).

--Andy
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 00/12] Add kdbus implementation

[Jiri Kosina]

On Wed, 29 Oct 2014, Greg Kroah-Hartman wrote:

 kdbus is a kernel-level IPC implementation that aims for resemblance to
 the the protocol layer with the existing userspace D-Bus daemon while
 enabling some features that couldn't be implemented before in userspace.

I'd be interested in the features that can't be implemented in userspace 
(and therefore would justify existence of kdbus in the kernel). Could you 
please point me to such list / documentation?

It seems to me that most of the highlight features from the cover letter 
can be easily (for certain definition of that word, of course) 
implemented in userspace (vmsplice(), sending fd through unix socket, user 
namespaces, UUID management, etc).

Thanks,

-- 
Jiri Kosina
SUSE Labs

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 00/12] Add kdbus implementation

[Greg Kroah-Hartman]

On Thu, Oct 30, 2014 at 12:00:16AM +0100, Jiri Kosina wrote:
 On Wed, 29 Oct 2014, Greg Kroah-Hartman wrote:
 
  kdbus is a kernel-level IPC implementation that aims for resemblance to
  the the protocol layer with the existing userspace D-Bus daemon while
  enabling some features that couldn't be implemented before in userspace.
 
 I'd be interested in the features that can't be implemented in userspace 
 (and therefore would justify existence of kdbus in the kernel). Could you 
 please point me to such list / documentation?

Lennart has given whole talks about this in the past, here's a recent
talk going into the details:
https://www.youtube.com/watch?v=HPbQzm_iz_k

 It seems to me that most of the highlight features from the cover letter 
 can be easily (for certain definition of that word, of course) 
 implemented in userspace (vmsplice(), sending fd through unix socket, user 
 namespaces, UUID management, etc).

We have dbus in userspace today, but that requires extra copies of data,
and isn't easy, or even possible, to do some of the application-specific
bus logic that kdbus provides.  See the talk above for details, there
are slides around somewhere with just text that we can add to the cover
letter if that will help out in future spins of this patch series.

thanks,

greg k-h
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 00/12] Add kdbus implementation

[Greg Kroah-Hartman]

On Wed, Oct 29, 2014 at 04:11:06PM -0700, Greg Kroah-Hartman wrote:
 On Thu, Oct 30, 2014 at 12:00:16AM +0100, Jiri Kosina wrote:
  On Wed, 29 Oct 2014, Greg Kroah-Hartman wrote:
  
   kdbus is a kernel-level IPC implementation that aims for resemblance to
   the the protocol layer with the existing userspace D-Bus daemon while
   enabling some features that couldn't be implemented before in userspace.
  
  I'd be interested in the features that can't be implemented in userspace 
  (and therefore would justify existence of kdbus in the kernel). Could you 
  please point me to such list / documentation?
 
 Lennart has given whole talks about this in the past, here's a recent
 talk going into the details:
   https://www.youtube.com/watch?v=HPbQzm_iz_k
 
  It seems to me that most of the highlight features from the cover letter 
  can be easily (for certain definition of that word, of course) 
  implemented in userspace (vmsplice(), sending fd through unix socket, user 
  namespaces, UUID management, etc).
 
 We have dbus in userspace today, but that requires extra copies of data,
 and isn't easy, or even possible, to do some of the application-specific
 bus logic that kdbus provides.  See the talk above for details, there
 are slides around somewhere with just text that we can add to the cover
 letter if that will help out in future spins of this patch series.

Here's an article describing it as well:
https://lwn.net/Articles/580194/
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 00/12] Add kdbus implementation

[Jiri Kosina]

On Wed, 29 Oct 2014, Greg Kroah-Hartman wrote:

   kdbus is a kernel-level IPC implementation that aims for resemblance to
   the the protocol layer with the existing userspace D-Bus daemon while
   enabling some features that couldn't be implemented before in userspace.
  
  I'd be interested in the features that can't be implemented in userspace 
  (and therefore would justify existence of kdbus in the kernel). Could you 
  please point me to such list / documentation?
 
 Lennart has given whole talks about this in the past, here's a recent
 talk going into the details:
   https://www.youtube.com/watch?v=HPbQzm_iz_k

I think it's a reasonable expectation that kernel patch submissions should 
be reasonably self-contained though. We've always been very strict about 
pushing everybody to provide extensive cover letters, changelogs and 
explanations, so this shouldn't really be an exception, I think.

  It seems to me that most of the highlight features from the cover letter 
  can be easily (for certain definition of that word, of course) 
  implemented in userspace (vmsplice(), sending fd through unix socket, user 
  namespaces, UUID management, etc).
 
 We have dbus in userspace today, but that requires extra copies of data,

But we can do zero-copy between processess for quite some time already, so 
what exactly is the issue here?

 and isn't easy, or even possible, to do some of the application-specific
 bus logic that kdbus provides.  

I unfortunately have absolutely no idea what should I imagine here.

 See the talk above for details, there are slides around somewhere with 
 just text that we can add to the cover letter if that will help out in 
 future spins of this patch series.

I think that would be very helpful. Thanks.

-- 
Jiri Kosina
SUSE Labs

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 00/12] Add kdbus implementation

[Jiri Kosina]

On Thu, 30 Oct 2014, Jiri Kosina wrote:

   It seems to me that most of the highlight features from the cover letter 
   can be easily (for certain definition of that word, of course) 
   implemented in userspace (vmsplice(), sending fd through unix socket, 
   user 
   namespaces, UUID management, etc).
  
  We have dbus in userspace today, but that requires extra copies of data,
 
 But we can do zero-copy between processess for quite some time already, so 
 what exactly is the issue here?
 
  and isn't easy, or even possible, to do some of the application-specific
  bus logic that kdbus provides.  
 
 I unfortunately have absolutely no idea what should I imagine here.

Also, I think I have heard that binder is going out of staging now, right?

I admittedly have very limited understanding of both binder and kdbus, but 
I guess that is the case for many folks. My understanding is that they are 
providing very similar functionality, so explanation why we need *both* in 
the kernel would be very interesting as well.

-- 
Jiri Kosina
SUSE Labs

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 00/12] Add kdbus implementation

[Greg Kroah-Hartman]

On Thu, Oct 30, 2014 at 12:26:33AM +0100, Jiri Kosina wrote:
 On Thu, 30 Oct 2014, Jiri Kosina wrote:
 
It seems to me that most of the highlight features from the cover 
letter 
can be easily (for certain definition of that word, of course) 
implemented in userspace (vmsplice(), sending fd through unix socket, 
user 
namespaces, UUID management, etc).
   
   We have dbus in userspace today, but that requires extra copies of data,
  
  But we can do zero-copy between processess for quite some time already, so 
  what exactly is the issue here?
  
   and isn't easy, or even possible, to do some of the application-specific
   bus logic that kdbus provides.  
  
  I unfortunately have absolutely no idea what should I imagine here.
 
 Also, I think I have heard that binder is going out of staging now, right?

Yes, but that needs documentation, which I'm working on at the moment :)

 I admittedly have very limited understanding of both binder and kdbus, but 
 I guess that is the case for many folks. My understanding is that they are 
 providing very similar functionality, so explanation why we need *both* in 
 the kernel would be very interesting as well.

They do very different things, see this writeup I did a while ago about
the differences between them:
http://kroah.com/log/blog/2014/01/15/kdbus-details/

thanks,

greg k-h
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 00/12] Add kdbus implementation

[Greg Kroah-Hartman]

On Thu, Oct 30, 2014 at 12:24:02AM +0100, Jiri Kosina wrote:
 On Wed, 29 Oct 2014, Greg Kroah-Hartman wrote:
 
kdbus is a kernel-level IPC implementation that aims for resemblance to
the the protocol layer with the existing userspace D-Bus daemon while
enabling some features that couldn't be implemented before in userspace.
   
   I'd be interested in the features that can't be implemented in userspace 
   (and therefore would justify existence of kdbus in the kernel). Could you 
   please point me to such list / documentation?
  
  Lennart has given whole talks about this in the past, here's a recent
  talk going into the details:
  https://www.youtube.com/watch?v=HPbQzm_iz_k
 
 I think it's a reasonable expectation that kernel patch submissions should 
 be reasonably self-contained though. We've always been very strict about 
 pushing everybody to provide extensive cover letters, changelogs and 
 explanations, so this shouldn't really be an exception, I think.

There is a 1815 line documentation file in this series, so we aren't
trying to not provide this type of information here at all.  But yes,
more background, about why this can't be done in userspace (zero copy,
less context switches, proper credential passing, timestamping, availble
at early-boot, LSM hooks for security models to tie into, race-free
interfaces, container/namespace support, etc.) should be added to the
docs as well.

   It seems to me that most of the highlight features from the cover letter 
   can be easily (for certain definition of that word, of course) 
   implemented in userspace (vmsplice(), sending fd through unix socket, 
   user 
   namespaces, UUID management, etc).
  
  We have dbus in userspace today, but that requires extra copies of data,
 
 But we can do zero-copy between processess for quite some time already, so 
 what exactly is the issue here?

See the above list for more details.

We'll work on this for the next round of patches, thanks.

greg k-h
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 00/12] Add kdbus implementation

[Andy Lutomirski]

On Wed, Oct 29, 2014 at 4:40 PM, Greg Kroah-Hartman
gre...@linuxfoundation.org wrote:
 On Thu, Oct 30, 2014 at 12:24:02AM +0100, Jiri Kosina wrote:
 On Wed, 29 Oct 2014, Greg Kroah-Hartman wrote:

kdbus is a kernel-level IPC implementation that aims for resemblance to
the the protocol layer with the existing userspace D-Bus daemon while
enabling some features that couldn't be implemented before in 
userspace.
  
   I'd be interested in the features that can't be implemented in userspace
   (and therefore would justify existence of kdbus in the kernel). Could you
   please point me to such list / documentation?
 
  Lennart has given whole talks about this in the past, here's a recent
  talk going into the details:
  https://www.youtube.com/watch?v=HPbQzm_iz_k

 I think it's a reasonable expectation that kernel patch submissions should
 be reasonably self-contained though. We've always been very strict about
 pushing everybody to provide extensive cover letters, changelogs and
 explanations, so this shouldn't really be an exception, I think.

 There is a 1815 line documentation file in this series, so we aren't
 trying to not provide this type of information here at all.  But yes,
 more background, about why this can't be done in userspace (zero copy,
 less context switches, proper credential passing, timestamping, availble
 at early-boot, LSM hooks for security models to tie into, race-free
 interfaces, container/namespace support, etc.) should be added to the
 docs as well.

It's worth noting that:

 - Proper credential passing could be added to UNIX sockets, and we
may want to do that anyway.  Also, the current kdbus semantics seem to
be spew lots of credentials and other miscellaneous
potentially-sensitive and sometime spoofable information all over the
place, which isn't obviously an improvement.  (This is fixable, but
it will almost certainly not be compatible with current systemd kdbus
code if fixed.)

 - The current kdbus patches seem to be worse than UNIX sockets from a
namespace perspective, but maybe I'm misunderstanding how it's
supposed to work.  UNIX sockets work quite nicely in containers.

 - There's an obvious interface to add timestamping to UNIX sockets
(it could work exactly the way it does for UDP / PTP).

 - I'm unconvinced by this performance argument without numbers.  The
kdbus credential code, at least, looks to be quite heavy on allocation
and atomics.  This isn't to say that the current userspace D-Bus
daemon doesn't also serialize everything, but it could be made
multithreaded.

 - Race-free?  What are the races that are inherent to UNIX sockets?

--Andy
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 00/12] Add kdbus implementation

[Andy Lutomirski]

On Wed, Oct 29, 2014 at 3:27 PM, Greg Kroah-Hartman
gre...@linuxfoundation.org wrote:
 On Wed, Oct 29, 2014 at 03:15:51PM -0700, Andy Lutomirski wrote:
 (reply 1/2 -- I'm replying twice to keep the threading sane)

 On Wed, Oct 29, 2014 at 3:00 PM, Greg Kroah-Hartman
 gre...@linuxfoundation.org wrote:
  kdbus is a kernel-level IPC implementation that aims for resemblance to
  the the protocol layer with the existing userspace D-Bus daemon while
  enabling some features that couldn't be implemented before in userspace.
 

   * Support for multiple domains, completely separated from each other,
 allowing multiple virtualized instances to be used at the same time.

 Given that there is no such thing as a device namespace, how does this work?

 See the document for the details.

They seem insufficient to me, so I tried to dig in to the code.  My
understanding is:

The parent container has /dev mounted.  It sends an IOCTL (which
requires global capabilities).  In response, kdbus creates a whole
bunch of devices that get put (by udev or devtmpfs, I presume) in a
subdirectory.  Then the parent container mounts that subdirectory in
the new container.

This is IMO rather problematic.

First, it enforces the existence of a kdbus domain hierarchy where
none should be needed.

Second, it's incompatible with nested user namespaces.  The middle
namespace can't issue the ioctl.

Third, it requires a devtmpfs submount in the child container.  This
scares me, especially since there are no device namespaces.  Also, the
child container appears to be dependent on the host udev to arbitrate
everything, which seems totally wrong to me.  (Also, now we're exposed
to attacks where the child container creates busses or endpoints or
whatever with malicious names to try to trick the host into screwing
up.)

ISTM this should be solved either with device namespaces (which is
well known to be a giant can of worms) or by abandoning the concept of
kdbus using device nodes entirely.

What if kdbus were kdbusfs?  If you want to use it in a container, you
mount a brand-new kdbusfs there.  No weird domain hierarchy, no global
privilege, no need to name containers, obvious migration semantics, no
dependence on udev/devtmpfs at all, etc.

Eric, any thoughts here?

--Andy
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 00/12] Add kdbus implementation

[Eric W. Biederman]

Greg KH gre...@linuxfoundation.org writes:

 On Wed, Oct 29, 2014 at 03:00:44PM -0700, Greg Kroah-Hartman wrote:
 kdbus is a kernel-level IPC implementation that aims for resemblance to
 the the protocol layer with the existing userspace D-Bus daemon while
 enabling some features that couldn't be implemented before in userspace.

 {sigh}

 I'll blame it on the jet-lag for the lack of [XX/12] markings on the
 patches.  I'll give it a day for review before resending if people
 really want to know the ordering.  It doesn't matter except for the
 final patch that adds the code to the build file.

 sorry about that,

For what it is worth these patches are also poorly split up.  Every
patch I looked at in detail had functions that were being introduced
that did not have callers.

That poor split up of the patches makes it difficult to see how
the functionality that is being introduced is being used.

Eric
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 00/12] Add kdbus implementation

[Eric W. Biederman]

The userspace API breaks userspace in an unfixable way.

Nacked-by: Eric W. Biederman ebied...@xmission.com

Problem the first.
- Using global names for containers makes it impossible to create
  unprivileged containers.

  This is a back to the drawing board problem, and makes device
  nodes fundamentally unsuited to what you are doing.

  There is no way that I can see to make it safe for an unprivileged
  user to create arbitrary named busses.  Especially in the presence
  of allowing unprivileged checkpoint/restart.

  This is particularly bad as kdbus explicitly allows unprivielged
  creation of new kdbus instances.

  This problem is a userspace regression.

Problem the second.
- The security checks in the code are not based on who opens the
  file descriptors but instead based on who is used the file
  descriptors at any give moment.

  That pattern has been shown to be exploitable.

  I expect the policy database makes this poor choice of permission
  checks even worse.  Pass a more privileged user a kdbus file
  descriptor and all of sudden things that were not possible on
  that file descriptor become possible.

Problem the third.
- You are using device numbers for things created by unprivileged
  users.  That breaks checkpoint/restart.  Aka CRIU.

  We can not migrate a container to a new machine and preserve the
  device numbers.  

  We can not migrate a container to a new machine and have any hope
  of preserving the container patsh under /dev/kdbus/...

  Both of which look like fundamental show stoppers for
  checkpoint/restart.

Andy Lutomirski l...@amacapital.net writes:

 On Wed, Oct 29, 2014 at 3:27 PM, Greg Kroah-Hartman
 gre...@linuxfoundation.org wrote:
 On Wed, Oct 29, 2014 at 03:15:51PM -0700, Andy Lutomirski wrote:
 (reply 1/2 -- I'm replying twice to keep the threading sane)

 On Wed, Oct 29, 2014 at 3:00 PM, Greg Kroah-Hartman
 gre...@linuxfoundation.org wrote:
  kdbus is a kernel-level IPC implementation that aims for resemblance to
  the the protocol layer with the existing userspace D-Bus daemon while
  enabling some features that couldn't be implemented before in userspace.
 

   * Support for multiple domains, completely separated from each other,
 allowing multiple virtualized instances to be used at the same time.

 Given that there is no such thing as a device namespace, how does this work?

 See the document for the details.

 They seem insufficient to me, so I tried to dig in to the code.  My
 understanding is:

 The parent container has /dev mounted.  It sends an IOCTL (which
 requires global capabilities).  In response, kdbus creates a whole
 bunch of devices that get put (by udev or devtmpfs, I presume) in a
 subdirectory.  Then the parent container mounts that subdirectory in
 the new container.

 This is IMO rather problematic.

 First, it enforces the existence of a kdbus domain hierarchy where
 none should be needed.

 Second, it's incompatible with nested user namespaces.  The middle
 namespace can't issue the ioctl.

 Third, it requires a devtmpfs submount in the child container.  This
 scares me, especially since there are no device namespaces.  Also, the
 child container appears to be dependent on the host udev to arbitrate
 everything, which seems totally wrong to me.  (Also, now we're exposed
 to attacks where the child container creates busses or endpoints or
 whatever with malicious names to try to trick the host into screwing
 up.)

 ISTM this should be solved either with device namespaces (which is
 well known to be a giant can of worms) or by abandoning the concept of
 kdbus using device nodes entirely.

 What if kdbus were kdbusfs?  If you want to use it in a container, you
 mount a brand-new kdbusfs there.  No weird domain hierarchy, no global
 privilege, no need to name containers, obvious migration semantics, no
 dependence on udev/devtmpfs at all, etc.

 Eric, any thoughts here?

I think a kdbusfs modeled on devpts with newinstance at
mount time would solve the naming problems.

That would break one of the current kdbus use cases that allows an
unprivileged user to create a bus.

Eric

p.s.  Please excuse my brevity I have am in the middle of packing up my
possessions (including my main machine), as I move this week.


--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/