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
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(),
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 e
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 so
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 con
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 coul
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 questio
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 m
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 q
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-
> > 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
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
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
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:
>>
>>>
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
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 ser
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 cr
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 creatio
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
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
>> unp
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
[ 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.
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.
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 cre
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
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 l
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 s
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
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 i
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 implem
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 e
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 featur
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 users
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,
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 in
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
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 coul
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 feat
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
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 implem
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 tim
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 w
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,
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 th
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
(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 c
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 p
47 matches
Mail list logo
