Manux – A free Linux-compatible OS designed to withstand attacks in userspace(manux.info)
manux.info
Manux – A free Linux-compatible OS designed to withstand attacks in userspace
http://www.manux.info/en/
7 comments
Here's an approach being tried for desktop apps: https://blogs.gnome.org/alexl/2015/02/17/first-fully-sandbox...
That's cool.
I've toyed with PC-BSD, which has a per-application jail setup function called Warden. FreeBSD jails are supposedly a more secure version of standard chroot (which historically was pretty easy to break out of). I have always wondered about the vulnerability of X-Windows in the PC-BSD context, and if an untrusted jailed app could cause grief on the main desktop via X.
It's nice to see more stuff like this being experimented on. I recall reading about a similar Windows thing some time ago (Sandboxy?), but the concept never seemed to go mainstream for some reason.
I've toyed with PC-BSD, which has a per-application jail setup function called Warden. FreeBSD jails are supposedly a more secure version of standard chroot (which historically was pretty easy to break out of). I have always wondered about the vulnerability of X-Windows in the PC-BSD context, and if an untrusted jailed app could cause grief on the main desktop via X.
It's nice to see more stuff like this being experimented on. I recall reading about a similar Windows thing some time ago (Sandboxy?), but the concept never seemed to go mainstream for some reason.
"Always reboot electrically into it - don't simply reboot; power you computer down, then up again. That's because the mouse is not handled, and if you were to touch it, due to hardware technicalities, your keyboard would get stu"
"Keyboard would get stu" is just brilliant.
Otherwise, what is claimed sounds very impressive, so much that I really wonder "what's the catch? There must be some."
"Keyboard would get stu" is just brilliant.
Otherwise, what is claimed sounds very impressive, so much that I really wonder "what's the catch? There must be some."
> Otherwise, what is claimed sounds very impressive, so
> much that I really wonder "what's the catch? There must
> be some."
I didn't understand that part. What does 'Keyboard would get stu' mean?
keyboard would get stuck
and it got stuck before the 'ck'
Etgar Keret has a funny story titled Malffunction about buying a computer with a broken keyboard.
https://books.google.com/books?id=un6rKAjevT4C&pg=PA87&lpg=P...
https://books.google.com/books?id=un6rKAjevT4C&pg=PA87&lpg=P...
[deleted]
Capability-based OSes have been around for some time, largely developed by the team that produced DRoPS, Fiasco, and other L4 based systems (as tonyhb pointed out).
Those advances are mostly from the Dresden OS folks, and the NICTA group (which went on to make one of Qualcomm's best kernels, OKL4).
seL4 was an attempt to convert the API and specification for the L4 kernel into an executable format (using Haskell) and confirm the specification was solid. The system was then extended to actually test the L4 kernel itself.
In the most recent versions, you can run entire device drivers and OS layers under the capability management system. One only needs to look at the Genode tooling (which is the logical continuation of the work started in DRoPS): http://genode.org/documentation/general-overview/index
Genode, Fiasco.OC, L4 (including seL4), and the work on secure GUIs all deserve to be far more popular than they are.
Those advances are mostly from the Dresden OS folks, and the NICTA group (which went on to make one of Qualcomm's best kernels, OKL4).
seL4 was an attempt to convert the API and specification for the L4 kernel into an executable format (using Haskell) and confirm the specification was solid. The system was then extended to actually test the L4 kernel itself.
In the most recent versions, you can run entire device drivers and OS layers under the capability management system. One only needs to look at the Genode tooling (which is the logical continuation of the work started in DRoPS): http://genode.org/documentation/general-overview/index
Genode, Fiasco.OC, L4 (including seL4), and the work on secure GUIs all deserve to be far more popular than they are.
Any way to get it running in a virtual machine without having a real hard drive to put it on?
It's probably easier to get it running in a VM, since it expects a very plain 32-bit IBM-compatible machine and doesn't handle modern things like USB. Just set your VM to emulate the oldest hardware it supports.
Yeah, but I'm not sure how to get it onto the virtual HDD in the first place. The instructions given depend on real hardware. Thinking about it, I suppose I could install Linux in the virtual machine, and follow the instructions there..
Update: Managed to get it installed to its own hard drive in virtualbox by hacking the install script to allow it. Unfortunately, it kernel panics during boot. I'll try again, this time with a Linux live cd
Is chroot the only protection against a hostile process?
Chroot (grsecurity makes this a lot better), the various namespaces, syslinux, seccomp.
Seccomp has strict mode, which allows you to say to the kernel "from this point on, allow me to only do read, write (to fd's I already have opened), _exit and sigreturn, otherwise kill the program". It's not perfect, but it reduces the vunrel space a lot.
You can also do a lot more fancy stuff, using the seccomp BPF interface (which I'm totally not writing a Haskell DSL for right now :D)
Seccomp has strict mode, which allows you to say to the kernel "from this point on, allow me to only do read, write (to fd's I already have opened), _exit and sigreturn, otherwise kill the program". It's not perfect, but it reduces the vunrel space a lot.
You can also do a lot more fancy stuff, using the seccomp BPF interface (which I'm totally not writing a Haskell DSL for right now :D)
Pretty much. There's always the option of putting it in a container (using Docker, for instance) or VM but chroot is probably the most commonly used and has the least overhead.
In this OS, are chroots enough to "withstand zero-day attacks in userspace", e.g. in combination with other hardening features?
Yes, the lack of a network stack prevents the most common attacks, and drastically reduces the usefulness of gaining control of the system.
I had to look up "zero-day attack", but it really meant what I thought it did, i.e. a previously unreported ("fresh") exploit (http://en.wikipedia.org/wiki/Zero-day_attack).
I don't understand this usage, which makes it sound as if zero-day attacks are a technical term, a category of attacks. Can anyone clarify?
I don't understand this usage, which makes it sound as if zero-day attacks are a technical term, a category of attacks. Can anyone clarify?
It's more of a business term, e.g. http://en.wikipedia.org/wiki/Vupen
Docker is not a security thing!
I hear this refrain a lot but I never really understood it. Could you explain? I would personally feel much more comfortable running a process as a unique user in an fresh Ubuntu container than running it in a chroot. One needn't go far to find a huge number of chroot escape methods.
Assuming this is aiming to be a Linux replacement, GPLv3 certainly isn't the right choice for a license.
From http://www.manux.info/en/:
"The kernel was written from scratch"
"shares no code with the Linux kernel"
It's not Linux, just Linux compatible. So I guess the author can apply any license they fancy.
"The kernel was written from scratch"
"shares no code with the Linux kernel"
It's not Linux, just Linux compatible. So I guess the author can apply any license they fancy.
Not what I meant. A large part of Linux's success came from companies contributing their code and using it. Companies really don't like GPLv3 because of it's Tivoization stuff.
Do you have data to support that claim, or is it just one of those thing some people chose to believe?
If we were to go and do a gitblame on the whole source tree, how high percentage would account for companies that produce/depend on DRM? 75% (majority), 25%(strong minority) or some 0.00something which barely register.
If we were to go and do a gitblame on the whole source tree, how high percentage would account for companies that produce/depend on DRM? 75% (majority), 25%(strong minority) or some 0.00something which barely register.
Watching https://www.youtube.com/watch?v=lRndE7rSXiI and it says that it's mathematically impossible for seL4 to suffer from things such as buffer overflows.
I'm faaaaaar out of my field here... but this sounds as like a far better improvement in security compared to running things in a chroot. Apart from it being really new (there's just a kernel with a C compiler), would this be a good route to head down for improving security? Why aren't we writing a linux port on this?
Kernel info here: http://en.wikipedia.org/wiki/L4_microkernel_family#High_assu...