Minijail build for Pyra PND system

[Shlee]

Hey, this is a beautiful tool and I'd love to see this used earlier in the design of the new Pyra PND system.

Mount the PND and load the binary within a user/id namespace minijail. this takes advantage of the new kernel features and allows the use of seccomp security for applications that support it.

This kind of tool shouldn't cause any major performance issues, but I'm keen to see if any of the dev team are interested in some security focus

cite:
https://www.chromium.org/chromium-os/developer-guide/chromium-os-sandboxing
https://lwn.net/Articles/700557/

 

[TrashyMG]

@slaeshjag would be the guy to talk to...

 

[Magic Sam]

Hi all

@Shlee : minijail looks like an interesting project, thanks for sharing !

I wondered elsewhere on the boards whether Docker would run on the Pandora (with armhf support) or not...

I guess minijail would be a lighter alternative to Docker in our case. Opinions ?

Cheers, Magic Sam

 

[Haraldur]

I have not watched the video, but there are other options to consider as well: firejail and bubblewrap, that I know of. I like that this is being worked on by so many different projects, as I think that the future of a mass-market GNU/Linux desktop system is to distribute non-system software like Windows: standalone executables (possibly in folders with data and libraries) downloaded from the web from perhaps-untrustworthy sources. Give me convenience, or give me death!

 

[levi]

This seems to involve chrooting, so that would be incompatible with projects such as wxpython or timidity, or speaking technically, other DBPs trying to discover the mount point of such projects.

But it might be useful for trying out DBPs though. Would be better if it could tell you about attempts to break out of its jail though, a little like you can control permissions in cyanogen though, just chrooting and hiding most of the ps table won't tell you that.

 

[slaeshjag]

While I can see the appeal of running such software in a jail, I'm not yet convinced that integration will work competently. If anyone have an idea of how to implementing it in practice rather than just listing technologies, I'd consider adding it as a configuration option for those who wants it. But system-wide access and integration close to that you get with it installed right onto your system drive is kinda of a big feature for me.

The general requirement is that it must not require root access to start the jail, dbp-run does not have that, and I'd muchly prefer not to suid it.

 

[Haraldur]

The general requirement is that it must not require root access to start the jail, dbp-run does not have that, and I'd muchly prefer not to suid it.

I have only used firejail, but that does not require root access. Assuming there is some command-line program for running DBPs, then the usage would be: 'firejail <options> DBP_runner audacious.dbp' (though the success of that depends on what the DBP_runner needs to access, as firejail might need to be told to give extra permissions). I have little idea of how DBP works, but if it creates a virtual file system and then just runs the main executable, then just putting 'firejail <options>' in front could suffice (though some programs may need specific options for specific permissions).

firejail is the sandbox suggested on the AppImage website (as AppImage does not have a built-in sandbox as yet).

 

[slaeshjag]

dbp-run will send a bunch of commands to dbpd over dbus, which will set up the aufs and mount the image. After that, it'll chdir into the aufs root and execute a given binary using a runscript in /etc. Any kind of jailing would likely have to happen in the run script.

 

[Askarus]

Minijail: Running untrusted programs safely.

That says it all. I don't trust any DBP uploaded here.