
Sailor, a native and portable container system for NetBSD and Mac OS X - petepete
https://github.com/NetBSDfr/sailor
======
noselasd
While neat and useful - is it fair to call this a container ? It seems to only
partition/isolate the filesystem(perhaps network interface too) - while
(arguably) the benefit of containers is being able to also partition and
isolate CPU, memory, network, routing, etc.

~~~
jacques_chester
Smarter people than me say that "true" containerizing on OS X is not really a
thing[1].

[1] [https://github.com/vito/houdini](https://github.com/vito/houdini)

~~~
geofft
OS X doesn't provide kernel features directly equivalent to Linux's CLONE_*
and cgroups. But it does provide Seatbelt, a sandboxing policy layer, which
you could use with effort to implement something similar in end result. This
is what both iOS apps and desktop App Store apps use for security isolation.

Alternatively, you could ship a kernel module that added these features
(although that might be ridiculously complicated).

~~~
jacques_chester
Alex (aka vito) likes implementing things from scratch on weekends. So if you
surprised him with a github issue he might just take you up on that challenge.

------
INTPenis
This brings me back to when we were creating complex scripts to generate jails
on FreeBSD.

It seems to me that sailor is just a chroot, in other words it's just a jail
with a bunch of stuff crammed in there to make it work. Just like 10 years ago
on FreeBSD when you created a jail and had to make the system inside the jail
to make it work.

------
Esau
It should be pointed out that Pkgin is not installed by default with NetBSD,
although you can add it during the installer configuration. The reason I know
that is that I manually configure my NetBSD installs, as I do not like the
depend on configuration tools.

------
q3k
So, the default example for node.js spawns the worker as root in the
'container'. Since this is a simple chroot, the worker could execute a 90's
style chroot escape (open; mkdir; chroot; fchdir; chdir ../../../; chroot.)
and gain root on the host.

Is this a joke?

~~~
geofft
If your goal with containerization is to run _trusted_ applications that just
need bizarre systemwide configuration (possibly mutually-conflicting
configuration), and keep that configuration separate from the host, then no,
it's not a joke. This is a super useful use case for containers.

There's a strong case to be made that you should not be trusting Docker
containers for untrusted code; they're just also for configuration isolation,
not security isolation. After all, Docker runs on top of the Linux kernel....
If you want to run untrusted code, put it in a VM (kvm, bhyve, Xen, whatever).

~~~
SwellJoe
Docker has kernel support from cgroups (and other features). Vastly different
from a simple chroot. Maybe not as strong as full virtualization, but if we're
worried about kernel bugs that allow privilege escalation, we have to worry
about everything running on the system, because it is all surface area for
attacking kernel privilege escalation bugs.

Comparing Docker (or any Linux container using cgroups, like LXC) to chroot is
not accurate.

~~~
mintplant
> we have to worry about everything running on the system, because it is all
> surface area for attacking kernel privilege escalation bugs

Usually "everything running on tbe system" is trusted code. The threat would
be a bug in your software that allows remote code execution and could
potentially be combined with a kernel bug to achieve privilege escalation.

The game changes significantly when you're giving arbitrary user-supplied code
immediate access to make kernel calls. Now you're only one bug away from game
over. And you're trusting the security of your whole system with a mechanism
that wasn't really designed for security against untrusted code in the first
place.

~~~
SwellJoe
On that, we're agreed. The Docker ecosystem is scary for that reason. But,
"trusted code" is also wishful thinking in most deployments. So many
deployments are slapped together out of a bunch of random places. The way many
people use Docker just takes that to a slightly more terrifying new level of
risk.

e.g.: npm, go get, *brew (in particular, Homebrew, OMG; goddamned thing
installs everything, from webservers to databases, to run as the same user
with little warning about what kind of consequences that has), etc.

People do stupid shit all the time with their software deployments, is what
I'm trying to say.

I just didn't want people to think Docker (or other Linux containers) are
comparable to chroot. They really aren't the same thing.

~~~
yingbo
npm, go get, home-brew..It is alright to me, in fact. I would rather take the
risk and trust them, than doing so many manually things. They could introduce
safety risk, same as you buy a can of food from a superstore and eat it "as
the same user with little warning about what kind of consequences that has".

~~~
SwellJoe
I've made no suggestion of doing anything manually. That would likely be even
more dangerous.

There are well-known, and well-understood, automated methods of providing a
(mostly) trustworthy source for software installation. RPM+yum on CentOS,
deb+apt-get on Debian/Ubuntu. The packages can be signed and verified (so you
know you're getting what the vendor packaged), the OS-standard sources are
open source and easy for third parties to check and used on millions of
machines (so you know manipulation is likely to be spotted quickly), easy to
verify the versions you have with one command, easy to update to newer
versions when security issues arise, easy to verify the files currently
installed match (or don't) the ones that the package shipped with. And, it is
relatively easy to package ones own tools and put them into a local
repository, using the same methods to insure safe delivery to all of your
systems.

I understand using other methods of locally providing packages. And, I
understand that sometimes you have to go outside the vendor provided packages
(and can't build your own, using the same best practices). But, to imagine
that you can/should trust a big blob of data grabbed from the internet and
splooshed onto your system (sometimes as root!) using a pipe to /bin/sh, is
ridiculous. Don't do that in an automated fashion without explicitly checking
out what you're being delivered. And, I would probably opt to host my own
private repo of those things, so that I can re-verify any time there are
changes before they get splooshed out to all of my systems.

This is basic operations stuff here, and yet folks keep reinventing the wheel,
poorly, and aggressively marketing it as a superior wheel.

------
scythe
There is already a Lua web framework named Sailor:
[http://sailorproject.org/](http://sailorproject.org/) \-- since this is a
rather closely related problem domain, it might be nice to avoid name
collisions.

~~~
Spiritus
I fail to see how it's a closely related problem domain.

