Starch Linux: OpenBSD Atop Arch's Linux Kernel

Quote:

---

Originally Posted by ncopa

I never claimed that bsd jails are more secure, because I don't know those.

---

As far as I know, there is no known way to break out of a BSD jail in the default configuration on FreeBSD. If you modify a FreeBSD jail to add certain devices in /dev from the host to the jail, enable UNIX System V shared memory or a few other things, then it becomes possible to break out.

Quote:

---

Originally Posted by ryao

As far as I know, there is no known way to break out of a BSD jail in the default configuration on FreeBSD. If you modify a FreeBSD jail to add certain devices in /dev from the host to the jail, enable UNIX System V shared memory or a few other things, then it becomes possible to break out.

---

That is what I expected. Even the wikipedia article says that one of the three goals for a jail is security while Linux developers claimes that chroot is not and never has been a security tool.

I got a bit surprised to see someone claim that even Linux chroots are more secure than BSD jails. I guess someone on the internet is wrong... :)

Quote:

---

Originally Posted by ncopa

That is what I expected. Even the wikipedia article says that one of the three goals for a jail is security while Linux developers claimes that chroot is not and never has been a security tool.

I got a bit surprised to see someone claim that even Linux chroots are more secure than BSD jails. I guess someone on the internet is wrong... :)

---

Both jails and chroots are available on FreeBSD. They are not mutually exclusive. chroot is not and never has been a security tool on FreeBSD either.

Quote:

---

Originally Posted by systemd anals bsd

Linux chroots are far more secure then BSD jails or chroots. BSD jails make the crappy OS even more vulnerable.

---

Any facts on this? Or just your "informed opinion"?

Quote:

---

Originally Posted by ncopa

Static linking is generally a bad idea. You'll end up with multiple copies of same code in memory -> bloat. You'll probably end up using more memory than with glibc.

Check out Alpine Linux. Uses uclibc and busybox and shared libs.

---

There are strong and weak points with both static and dynamic linking. I do not even presume to know all the details, but a static binary does not have to be executed via the linker, so it is generally started faster (you might loose RAM but you win CPU...). Other strong points with static binaries is that they are portable (you do not have to package a bundle of dlls together with your binary) and will stay executeable on a specific architecture/kernel combination for a _very_ long time. An all-static OS like Plan9 is far from being bloated.

Another huge advantage is that the whole system does not break down if libc breaks.

For a standard desktop, static linking would probably be a bad thing. On the other hand, for small and true "unixy" applications, static linking against light-weight libraries makes a lot of sense.