BUS1 Documentation Published As The New Alternative To KDBUS

[EduRam]

There is more information in here

https://lists.linuxfoundation.org/pipermail/ksummit-discuss/2016-July/003047.html

[tomegun]

Kernel is good at enforcing security and its code quality is somewhat above average. User mode usually worse at it. Since kernel knows nothing about names, wouldn't usermode be able to play load of dirty tricks, eventually trying to take over or fake various important/sensitive services here and there?

That's a bit too vague to really comment on. Probably better to revisit this once we have some example implementation to refer to.

Basically I'm worried about the following scenario: it could be "container" with user namespace. Its admin gets "fake root" and could add new users into his container. As far as I understand, it happens via uid mappings, so container could potentially run with range of uids. Though I've mostly seen this from usermode side and syscalls mans (i.e. clone() and somesuch). I'm not expert in all areas of kernel, so I'm sorry if my question sounds stupid, but would these new users inherit same kuid? Containers always had plenty of issues with the fact users can occupy quite some extra memory on kernel side without accounting or limits, eventually screwing things up.

Look up how something like fd accounting works, should be the same.

I understand it is incomplete and I have idea what WIP means, so do not take it as offence, etc. Another stupid question is: web site claims there is init, activator and administrator. Are these going to be separate processes? "Bootstrap" process looks somewhat complicated and I wonder why it looks like this. It also mentions bus's init bootstrapping bus is pid 1, but .. hmm, does it means it going to be systemd? Or it supposed to be something else? This makes me really puzzled. I guess I should go read some code instead of asking stupid questions, sorry

Those would be separate processes, yes. Not much code to read yet I'm afraid. This stuff really isn't ready for public consumption. That said, what exists is there, so anyone who is curious is free to poke around. I'm sure there will be some announcement once it actually is in a state that people are expected to be able to make sense of it.

[SystemCrasher]

As is hopefully clear, this is very much work in progress (some of the pages are even stubs).

Yeah, I've noticed it

See above But to answer your questions a bit: service discovery would be done purely in userspace, and so would mappings between names and handles. The kernel does not know anything about names.

That makes me somewhat worried. Kernel is good at enforcing security and its code quality is somewhat above average. User mode usually worse at it. Since kernel knows nothing about names, wouldn't usermode be able to play load of dirty tricks, eventually trying to take over or fake various important/sensitive services here and there? Though when it comes to security I would really prefer to see opinions of someone like Andy Lutimirski and somesuch, who appear to be much better experts in this area than me.

All quotas are per kuid, so creating new namespaces won't let you circumvent the limits.

Basically I'm worried about the following scenario: it could be "container" with user namespace. Its admin gets "fake root" and could add new users into his container. As far as I understand, it happens via uid mappings, so container could potentially run with range of uids. Though I've mostly seen this from usermode side and syscalls mans (i.e. clone() and somesuch). I'm not expert in all areas of kernel, so I'm sorry if my question sounds stupid, but would these new users inherit same kuid? Containers always had plenty of issues with the fact users can occupy quite some extra memory on kernel side without accounting or limits, eventually screwing things up.

Happy to answer questions, but it probably will be a lot simpler to understand all of this once we have working code, completed the documentation and got some examples running. After all, this project has not even been announced yet...

I understand it is incomplete and I have idea what WIP means, so do not take it as offence, etc. Another stupid question is: web site claims there is init, activator and administrator. Are these going to be separate processes? "Bootstrap" process looks somewhat complicated and I wonder why it looks like this. It also mentions bus's init bootstrapping bus is pid 1, but .. hmm, does it means it going to be systemd? Or it supposed to be something else? This makes me really puzzled. I guess I should go read some code instead of asking stupid questions, sorry

[Naib]

Have any of you actually looked at "BUS1"
The usual suspects are peddling it as a new in-kernel IPC

KDBus was an in-kernel IPC as they attempted to shoehorn dbus into the kernel for marginal speed inprovements but glaring security holes and bad code...

BUS1 does have some kernel stuff BUT it is an init and device manager with a lot of userland parts.

those associated with Systemd need to stop misrepresenting stuff and blurring boundaries... Make bus1 kernel IPC... make a device and init system as something that uses DONT mix the two because kernel, init, device are separate things...

[tomegun]

This said, bus1 mans are funny.

As is hopefully clear, this is very much work in progress (some of the pages are even stubs).

Hey, are there services discovery at all? And how the hell these "something.org.bus1" names are getting mapped into handles, nodes and somesuch? Are there any sensible overwies of security model? Vague descriptions do not answer quite many questions like "what if ... ?".

See above But to answer your questions a bit: service discovery would be done purely in userspace, and so would mappings between names and handles. The kernel does not know anything about names.

Say, memory is per-user. Okay, but when it comes to containers, container could run in separate users namespace, with "fake root". Such "fake root" could create shitload of users in their container. So it could try to waste quite some memory, according to such description. What would happen next? In perfect world, container would hit limits and error out locally. But I suspect it could rather be able to waste a plenty of "global" kernel memory instead, eventually fucking everything up, etc.

All quotas are per kuid, so creating new namespaces won't let you circumvent the limits.

Happy to answer questions, but it probably will be a lot simpler to understand all of this once we have working code, completed the documentation and got some examples running. After all, this project has not even been announced yet...

[SystemCrasher]

Probably the first bus that starts rolling everyday in Nicaragua, therefore "Bus 1".

This picture also outlines current state of IPC and kernel <-> user interfaces in Linux. Everybody builds their crap-house out of whatever garbage they managed to scavenge, being quite crappy builders either and unable or unwilling to afford better expertise for some reasons, or at least not willing to make it available to general public. The result looks pretty much like this street: plenty of homegrown, extremely implementations of the same things. Say, kernel haves like a half dozen of ways to let usermode talk to it, configure it, pass various config/status/events related data beyond of syscalls in and out, and so on. E.g. ever heard of netlink? Uevent? Sysfs, procfs, configfs/gadgetfs, IOCTLs, .... and then, user mode reinvents their own ways of doing obvious things, because there was no good system-level facilities doing this kind of things for them. I bet it could be better than that. Isn't it funny such a basic thing like listing processes is "optional"? You have to mount /proc first, it could eventually fail, or get mounted at truly unexpected place, or not mounted at all. It could be also not compiled in at all. So, listing running processes in particular Linux system not to be taken as something granted. And even all this cruft has worked out, you have to filter out unrelated spam like some kernel configuration/information cruft dumped here for some prehistoric reasons. Really perfect interface to usermode. Needless to say, it looks pretty similar to photo in article, isn't it?

This said, bus1 mans are funny. Hey, are there services discovery at all? And how the hell these "something.org.bus1" names are getting mapped into handles, nodes and somesuch? Are there any sensible overwies of security model? Vague descriptions do not answer quite many questions like "what if ... ?". Say, memory is per-user. Okay, but when it comes to containers, container could run in separate users namespace, with "fake root". Such "fake root" could create shitload of users in their container. So it could try to waste quite some memory, according to such description. What would happen next? In perfect world, container would hit limits and error out locally. But I suspect it could rather be able to waste a plenty of "global" kernel memory instead, eventually fucking everything up, etc.

[duby229]

Nope, you're just misinterpreting what you're seeing There's even a video here: http://www.williebus.com/

I see the dolly now. I thought the skirt looked like a doorway.

[GreatEmerald]

Th screwed up thing is that bus would never be able to turn, it's a fixed single with an axel directly in the center!

Nope, you're just misinterpreting what you're seeing There's even a video here: http://www.williebus.com/

[duby229]

I guess by that image Michael wanted to post something like this, but didn't have anything quite as rad: http://cdn2.ubergizmo.com/wp-content.../12/willie.jpg

Th screwed up thing is that bus would never be able to turn, it's a fixed single with an axel directly in the center!

[GreatEmerald]

I guess by that image Michael wanted to post something like this, but didn't have anything quite as rad: http://cdn2.ubergizmo.com/wp-content.../12/willie.jpg