linux-kernel - Re: A desktop environment[1] kernel wishlist

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <1414424723.30379.59.camel@hadess.net>
Date:	Mon, 27 Oct 2014 16:45:23 +0100
From:	Bastien Nocera <hadess@...ess.net>
To:	Andy Lutomirski <luto@...capital.net>
Cc:	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: A desktop environment[1] kernel wishlist

On Mon, 2014-10-27 at 08:12 -0700, Andy Lutomirski wrote:
> On Oct 27, 2014 6:56 AM, "Bastien Nocera" <hadess@...ess.net> wrote:
> >
> > On Tue, 2014-10-21 at 12:28 -0700, Andy Lutomirski wrote:
> > > On 10/21/2014 01:49 AM, Bastien Nocera wrote:
> > > > Hey,
> > > >
> > > > GNOME has had discussions with kernel developers in the past, and,
> > > > fortunately, in some cases we were able to make headway.
> > > >
> > > > There are however a number of items that we still don't have solutions
> > > > for, items that kernel developers might not realise we'd like to rely
> > > > on, or don't know that we'd make use of if merged.
> > > >
> > > > I've posted this list at:
> > > > https://wiki.gnome.org/BastienNocera/KernelWishlist
> > > >
> > > > Let me know on-list or off-list if you have any comments about those, so
> > > > I can update the list.
> > >
> > > I don't know much about desktop environment infrastructure, but I think
> > > the kernel probably already has a lot of what's needed for LinuxApps.
> > >
> > > Tools like Sandstorm [1] (shameless plug, but it's a good example here)
> > > can already sandbox normal-ish programs, and those sandboxes can be
> > > launched without privilege [2].
> > >
> > > Why is kdbus needed?
> >
> > Because it sucks less than passing fd's and using home-made protocols on
> > top of it.
> 
> For securely communicating with a container, "it sucks less" is hard
> to use as a design criterion.

Sucking less is a requirement when it comes to being able to use it. At
the very least, when it comes to security, the fact that the protocol
can be captured and analysed in wireshark is already of great help to
inspect what each component of the system is doing. More so than passing
fd's and using a custom protocol on the server and client sides.

> What's wrong with fds, and how does kdbus solve it?

By having a well-known protocol and defined semantics on top of that
communication channel. I could try and re-explain why kdbus is needed,
but I wouldn't do as good a job as the people working on it, so best to
refer to the individual threads about kdbus on this list.

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