Open Kagami opened 9 years ago
Hi Kagami, Are you still develop Kagome actively ? I'm interested by your implementation and ideas.
Hi. Not so much lately. It's just a small experimental project where I tried few ideas. I recommend you to look at firejail, subuser or x11-docker for a more polished solutions of container-based security. They also support xpra/xephyr for X11 isolation.
Ok, thanks a lot for your reply. I was interested to continue the development of your ideas. I've read about other implementations but there is a lot of Pros / Cons... I've tested Qubes (tried) but my hardware is too old for let it run smoothly... That's why I was interested by your project. Will you be open to questions or giving help ?
Yeap, sure. I'm also not quite satisfied with most current solutions and want to investigate further once I will have enough time for that.
Great ! I'm actually working also actively on another project (hosted on bitbucket) but I would like to contribute as much as I could with my free time on this project.
off topic: I've also seen that you also have interest in encoding stuff using FFMpeg, we may share knowledge ?
I'm mostly interested in WebM-related stuff. Feel free to contribute ;)
Sure ! Thanks for all Kagami :)
@Jiab77 would you mind listing for me the cons of subuser? I'm the author, so that's why I'm curious ;P
@timthelion Hello. I didn't seen a lot of cons about your software subuser
but most of them was about the use of docker
as container and all the security changes they should do in their concept but they don't.
Your concept and those of Kagami are interesting to me and I'll try your both solutions for my isolation experiments. I'd like to find the best solution that give me the security isolation I want and the possibility to play some games that requires OpenGL or make some grid computing with CUDA drivers.
Anyway thanks both for your reply :+1:
Note that access to OpenGL can allow attacker to break sandbox guarantees. E.g. it's possible to get contents of host windows by fetching GPU textures AFAIK. Check notes on OpenGL of Qubes project, it should have more details.
I know, I've read their paper but now what should be done if we just want to play games on our computers ? Don't play games on them ? Only use gaming console for that ? That's sad no ? Having so much power with new graphic cards and can't use them to do gaming, grid computing, or minning securely ?
Sorry so much questions...
Pretty simple fix is just use separate computer for that. Or second GPU, GPU passthrough is quite popular now.
Yes you're right that's the recommanded setup as explained there but actualy I just have one GPU on my setup. I should consider buying another one then test. Thanks a lot for your reply @Kagami
Hello @Kagami, I was just asking me what was you thought about using LXD containers to replace Docker containers ?
Don't know, I have only experience with Docker. From security point of view important pieces are seccomp-bpf, SELinux/AppArmor profiles, user namespaces. Maybe also some modern technics, haven't followed that topic lately.
Thanks a lot for this tips, I'll take a look at all of these.
Note that access to OpenGL can allow attacker to break sandbox guarantees. E.g. it's possible to get contents of host windows by fetching GPU textures AFAIK.
I think that may be an issue for privacy, but not a danger for the system. Once Xephyr accidently showed me some content of my GPU cache: http://up.picr.de/29178897fs.jpg I recognice the content of a firefox window showing some github statistics.
I'm more concerned about rootkits placing themselfes into the GPU. I found this example: https://github.com/x0r1/jellyfish , but no further useful comments on this topic. A second GPU would not improve this, I think, though this special rootkit afaik does not work on segregated GPUs. Closed source drivers offer additional vulnerabilities to attack the host.
I found graphical applications run fine with docker run option --cap-drop=ALL
. This disables some container privileges like user switching, chroot and chown.
Also, specifying option --user=someuserUID
avoids root running in container.
Using --user
and --cap-drop=ALL
improves docker security a lot (imho).
Very interesting, thank you @mviereck
cli image tends to have a lot of zombie processes because spawned background processes aren't reaped by the container's init (interactive sudo). More detail explanation: https://blog.phusion.nl/2015/01/20/docker-and-the-pid-1-zombie-reaping-problem/ Article recommends to use bash as a simplest init system, but
sudo -i
should already spawn bash (zsh). Need to investigate it further.