HN Explorer

12 comments

[ 3.1 ms ] story [ 35.3 ms ] thread
kolev
"Download Source" vs "Star/Fork/Issues/Pull Requests" at GitHub? Is it just me, but when I see a project not using GitHub/Bitbucket, its credibility drops drastically? Of course, there are others like Linux distros, GNU, etc., but we know and understand the motivation there.
nacs
What is the issue? They're using Github: https://github.com/subuser-security/subuser
kolev
The issue is that it's no where on the webpage and the download is not from GitHub either.
nacs
Erm, that Github link is the "Download source" link
kolev
Maybe it is now, but not when this got posted hours and hours ago.
timthelion
Look, I did that on purpose. I don't want to make a brand name, Github, into a synonym for open source.
kolev
I have to agree with you given your point.
xtrumanx
> Is it just me, but when I see a project not using GitHub/Bitbucket, its credibility drops drastically?

It may be just you. Why does the credibility drop if it isn't using GitHub/BitBucket as long as the code is available easily?

kolev
I doubt it's just me though. Our lives are driven by heuristics and one of those is: "If something deviates from the norm, it's risky." For good or bad, the norm today is GitHub.
angry_octet
This is a really good concept. Not sure docker as configured will provide sufficient isolation, but with strict SElinux/AppArmor controls it is going to be way better than just hoping something you got from a PPA/pip/npm is safe. It is also good to see this as a security-in-depth component. Maybe those bash exploits wouldn't have been so catastrophic if everything touching the outside world was confined by default.

Also, since writing SElinux controls is so hard, this is a great way to package those controls for end users.

timthelion
Docker knows how to automatically configure AppArmor and SELinux to contain the containers. Seems almost redundant, but if you like checking twice, that's definitely a supported feature of Docker.
[dead] angry_octet
You are over simplifying. The generic policies that are applied to an LXC instance are a trade-off between usability and security. A tightly bounded security policy will allow possibly correct behavior and nothing more, and this is very specific to the program.

Additionally, different parts of the program may need different policies. For example, qmail is structured to have components with different confinment policies. (See http://linux.die.net/man/8/qmail_selinux).

In fact many programs need to be restructured in this way. It is noticeable that Mac App Store programs are given very limited access and many needed to be extensively modified (http://arstechnica.com/apple/2011/07/mac-os-x-10-7/9/). It seems Ubuntu is on the same course: https://wiki.ubuntu.com/SecurityTeam/Specifications/Applicat...