Playing Around With the Fuchsia OS (quarkslab.com) 102
Security and software development company Quarkslab played around with Google's new Fuchsia operating system, which could one day replace Android on smartphones and Chrome OS on laptops. The researchers "decided to give a quick look at Fuchsia, learn about its inner design, security properties, strengths and weaknesses, and find ways to attack it." Here's what they concluded: Fuchsia's micro kernel is called Zircon. It is written in C++. [...] Contrary to every other major OS, it appears rather difficult to target the Zircon kernel directly. A successful RCE (Remote Code Execution) on the world-facing parts of the system (USB, Bluetooth, network stack, etc) will only give you control over the targeted components, but they run in independent userland processes, not in the kernel. From a component, you then need to escalate privileges to the kernel using the limited number of syscalls you can access with the handles you have. Overall, it seems easier to target other components rather than the kernel, and to focus on components that you can talk to via IPC and that you know have interesting handles.
Overall, Fuchsia exhibits interesting security properties compared to other OSes such as Android. A few days of vulnerability research allowed us to conclude that the common programming bugs found in other OSes can also be found in Fuchsia. However, while these bugs can often be considered as vulnerabilities in other OSes, they turn out to be uninteresting on Fuchsia, because their impact is, for the most part, mitigated by Fuchsia's security properties. We note however that these security properties do not -- and in fact, cannot -- hold in the lowest layers of the kernel related to virtualization, exception handling and scheduling, and that any bug here remains exploitable just like on any other OS. All the bugs we found were reported to Google, and are now fixed.
Again, it is not clear where Fuchsia is heading, and whether it is just a research OS as Google claims or a real OS that is vowed to be used on future products. What's clear, though, is that it has the potential to significantly increase the difficulty for attackers to compromise devices.
Overall, Fuchsia exhibits interesting security properties compared to other OSes such as Android. A few days of vulnerability research allowed us to conclude that the common programming bugs found in other OSes can also be found in Fuchsia. However, while these bugs can often be considered as vulnerabilities in other OSes, they turn out to be uninteresting on Fuchsia, because their impact is, for the most part, mitigated by Fuchsia's security properties. We note however that these security properties do not -- and in fact, cannot -- hold in the lowest layers of the kernel related to virtualization, exception handling and scheduling, and that any bug here remains exploitable just like on any other OS. All the bugs we found were reported to Google, and are now fixed.
Again, it is not clear where Fuchsia is heading, and whether it is just a research OS as Google claims or a real OS that is vowed to be used on future products. What's clear, though, is that it has the potential to significantly increase the difficulty for attackers to compromise devices.
i hope an x86_64 port gets built (Score:3)
Re: (Score:2)
I'm holding out for an IA-64 port: my old Itanium hardware could use some new tricks.
Re: (Score:2)
OpenVMS is still alive and kicking. It will outlive us all.
Re: (Score:3)
If you want something with these microkernel security ideas implemented, then you might be interested in checking out Minix 3 [minix3.org], which is intended for real-world use. It's worth noting that micro-kernels do have a significant real-world performance penalty, sometimes up to 30% of CPU, which is why we don't all use them today.
Re: (Score:2)
so you're going to have a ton of trouble getting anything to run on it
You mean anything depending on POSIX features.
Re: (Score:2)
so you're going to have a ton of trouble getting anything to run on it
You mean anything depending on POSIX features.
Android is dependent on POSIX features, a long with a lot of Android apps. Google will have to either rewrite a lot of the Android stack, or make a POSIX compatibility layer (which will come with a real drop in performance, the size of which will depend on the skill of the implementors).
Avoid (Score:5, Interesting)
Apparently Android does not allow the level of spying that Google likes.
Security and privacy in Fuchsia are at the level the advertising team at Google likes them to be:
https://insights.dice.com/2018... [dice.com]
Here is the relevant part:
"Thereâ(TM)s already been at least one clash between advertising and engineering over security and privacy features of the fledgling operating system, according to a person familiar with the matter. The ad team prevailed, this person said"
Re: (Score:2)
Re: (Score:2)
if it dont get a network connection it cant spy on anybody
If it don't get a network connection, it's not going to do very well as a phone, is it?
Will it finally let me delete Chrome? No? Then it's "same shit, different sector, captain."
Re: (Score:2, Informative)
Apparently Android does not allow the level of spying that Google likes.
I'm not sure how you came up with this drivel but considering Google is in 100% control over Android and any spying related to it's Google Play program, if you think this has in any way anything to do with why Fuchsia is being developed then I suggest you get yourself medicated.
Re: (Score:3)
You should have posted the sentence directly before that one. Google’s ads business relies on an ability to target users based on their location and activity, and Fuchsia’s nascent privacy features would, if implemented, hamstring this important business.
Sounds like a good thing.
Re: (Score:2)
"if implemented" is the critical phrase. The sentence following suggests it won't be implemented.
Re: (Score:3)
However the question would be whether or not it would be any *worse* than the Linux based.
I would anticipate the answer is that Fuchsia had to back away from it, but linux also does not do whatever it was.
Re: (Score:2)
Expectations hinder progress.
Real progress is made only when we toss out learned expectations. Often when evolutionary ideas are too great, it takes a revolution to implement them. Revolutions are a result of large changes in, or replacement of expectations, where evolution is just modifying existing expectations.
All of that is to preface the fact that how we think of things today, (in this case the "won't be implemented") is largely based on how we do things today. A revolutionary change would be required
Re: (Score:1)
There’s already been at least one clash between advertising and engineering over security and privacy features of the fledgling operating system, according to a person familiar with the matter. The ad team prevailed, this person said.
And the fact that the ad team won doesn't mean the system will be less secure/private.
As a engineer/developer, security and privacy features piss me off. I want to access everything. I don't like SSL because I can't easily monitor the connection with Wireshark. I don't like encrypted files because I can't see anything on a hex editor, I definitely won't install SELinux on my development machine unless forced to and for debugging, in case of a crash, I want a full dump of your memory.
The ad team my actually
Yikes! (Score:3)
You have to assume an adversarial environment even in a closed network. Security has to be part of the design from the beginning.
Re: (Score:2)
Here hear. The concept of a closed network, or a local network, or an internal network, is obsolete. Threats come from other hosts, wherever they are, even virtual ones in your very own laptop...
Re:Yikes! (Score:4, Insightful)
It is not my view. Security is always annoying. Even the lock on your front door is annoying, if you didn't have it, you wouldn't have to bother with keys.
That's why there is always a trade-off between security and convenience, and that's why security is its own field, distinct from software development. A developer may be the right person to ask if you want to avoid buffer overflows and injection attacks, but he may not be able to tell when two factor authentication is called for if your IP address is considered sensitive data.
And BTW, we don't always need to assume an adversarial environment in safety-critical systems. For example, we assume pilots don't want to crash their plane, and avionic systems are typically very open. Being able to see what happens is more important than preventing would be hackers from messing with avionic buses that are typically isolated and only accessible by the crew.
Re: (Score:2)
Separating security from the developer is not only an outdated concept it is a dangerous mindset to have. Effective security depends on a holistic approach over the entire sys
Re: (Score:3)
The level of ignorance in your example on avionics is simply stunning--secure avionic systems are in active development.
If that's the case, I suggest you take cover, because there may be some code I worked on that is flying over your head ;)
I am not saying that secure avionics don't exist, but I am working on avionics right now (literally! Or more exactly, that what I should be doing instead of posting on Slashdot...) and none of the communications are encrypted. We are using a variety of buses: mostly ARINC-429 but also a bit of RS, CAN, variations on Ethernet, ... I don't remember seeing any encryption in any of the system
Re: Yikes! (Score:2)
My favorite example on on one simple step in writing secure code is making use of features within the language/compiler to prevent errors. Do you write if(foo == 47) Or if(47 == foo) You should always use the second one because it will generate a compil
Re:Avoid (Score:5, Informative)
> I definitely won't install SELinux on my development machine unless forced to and for debugging, in case of a crash, I want a full dump of your memory.
SELinux let's you decide who can dump the memory, using which programs. It doesn't stop you from doing whatever you want, it gives you more control. So for example you might say that gdb can access memory of another program; your web browser (and it's JavaScript engine) can't access the memory of an unrelated process. setrlimit is a SELinux tool to set the allowed size of a core dump.
You're hopefully familiar with classic Linux permissions, which let's you say who can access a file. SELinux is the same thing, with the addition of you can say via which program. You can say that your mail reader doesn't have access to /etc/shadow, regardless of it gets launched by something that root ran.
Also, the default for most distributions is called "targeted" policy. You decide that SELinux protects certain risky processes, such as a web server or anything else listening on the network. You might choose to apply it to your web browser, especially if you have a browser that you use for Flash sites. Up to you which you want to apply it to.
Insightful comment of the month! (Score:2)
In other words, Privacy and Security won't make you billions
Re: (Score:2)
This is new code, they can use something much closer to 100% C++ rather than the C that was the source of those errors.
Re: (Score:2)
Android has Java
But is not written in Java.
It is written in C++. (Score:5, Funny)
It is written in C++.
It's as if the voices of a million Rust programmers suddenly cried out, then were silenced.
Re: (Score:2)
Good [youtube.com].
Re: It is written in C++. (Score:4, Interesting)
I was thinking more of GNU Hurd developers. Fuchsia's architecture looks a lot like what they were trying to do.
Re: (Score:2)
I was thinking more of GNU Hurd developers. Fuchsia's architecture looks a lot like what they were trying to do.
I wouldn't be surprised if they've taken some inspiration from it. Turns out making a pure microkernel, efficient dekstop OS is not easy.
Half a thousand very loud ones (Score:3)
Half a million, or half a thousand, very loud Rust developers. :)
Old tech. (Score:5, Funny)
"Fuchsia's micro kernel is called Zircon. It is written in C++"
Pffth. The 90's called, they want their OS back. Any modern kernel should be written in Node.js, for unparalleled speed.
Re:Old tech. (Score:4, Funny)
And long time support.
Re: (Score:2)
Node.JS needs a real OS, with a kernel, libraries etc. just to start.
I even think that using C++ for a kernel isn't a good idea, let alone using anything like Node.JS, Python or Java.
Re: Old tech. (Score:2)
Re: (Score:2)
WHOOOOOOOOOOOSH!!!
lol
Re: (Score:2)
Node.JS needs a real OS, with a kernel, libraries etc. just to start.
Maybe Node.JS can run on Emacs . . . ?
Then if we could find a good editor written in Node.JS, we'd be all set.
I even think that using C++ for a kernel isn't a good idea, let alone using anything like Node.JS, Python or Java.
One of the fresher ideas in OS design is the concept of a Macrokernel . . . write the entire kernel in macros.
Then you just need to provide the implementations of the macros, and then the Node.JS, Python or Java preprocessor will generate the actual kernel code.
Re: (Score:2)
Is it webscale (Score:2)
that's what serious bears want to know
Re: (Score:1)
then it will be web scale
Node.js is Bad Ass Rock Star Tech! (Score:1)
Re: (Score:2)
Then the 60's called and said the new kernel should be written in PL/I, like Multics, for unparalleled security.
Owning the kernel is hardly a necessity anymore (Score:2)
If the vast amount of crypto trojans told us anything, then that you can have near infinite chance to wreak havoc if you own user space if the system you're hijacking has mostly one user.
And that's even more likely to be the case with phones than with desktop computers. Not that it wasn't already near 100% with desktop computers...
Re: (Score:2)
Yeah, but then sandboxing is more for that sort of stuff.
But if you can't trust the kernel, then how can you have decent sandboxing?
Re: (Score:2)
And everything is new again (Score:2)
This reminds me a lot of some of the ideas developed in the 1980s in the Chorus Distributed Operating System. Maybe someone got around to reading the history books?
Re: (Score:2)
How does this all relate to L4?
I know nothing about kernels, so it is an honest question.
Comment removed (Score:5, Informative)
Re: (Score:2)
And, to be honest, we've never actually moved to CPUs that do have that capability
Hold up now. I don't completely disagree with you on this point, but things like VAS and NX within the amd64 arch do somewhat provide the tools for process isolation. So while we aren't "at" that goal, we have at the least "moved towards" that goal.
Andrew Tannenbaum... (Score:4, Insightful)
Just called somewhere.
Re: (Score:2)
I hope Linus will replay.
Re: (Score:2)
I hope I have enough popcorn.
Sounds like marketing or a waste of time (Score:5, Interesting)
Or both.
Fuchsia ecosystem if very far from being stable under both the design and the implementation points of view.
Anything could be changing, even the actual delivery.
But showing off with a very speculative OS, even one from Google, is marketing.
Just like an interior design company talking about interior design for the spaceships that will bring people to Mars and eyond.
C'mon!
Re: (Score:2)
If Google port the Android APIs to it then it will instantly have a huge library of software available.
Android is a set of APIs that sits on top of a Linux kernel. The kernel can be swapped out, the whole underlying OS can be swapped out, as long as the APIs are available.
Re: (Score:2)
Then I would target my attacks to Android more than to the kernel itself, especially if the Fuchsia thing isn't stable yet.
Re: (Score:2)
You can do that but those APIs are a lot less interesting than kernel level stuff, which on current Linux systems includes drivers and a lot of other stuff. Once it's all moved out of the kernel compromising it is a lot less useful.
Re: (Score:2)
Of course the question is to what extent this concept is useful in and of itself versus flexing their technical skills.
There has been a long history of microkernel concepts from all corners, and thus far they either never got traction, or gave up a large chunk of their 'micro-ness' by the time they acheived significant adoption.
Re: (Score:2)
Of course the question is to what extent this concept is useful in and of itself versus flexing their technical skills.
Considering they have been working on it for all these years and have nothing practical to show for it, their technical skills aren't too impressive. Also their design decisions are questionable.
Re: (Score:2)
Of course the question is to what extent this concept is useful in and of itself versus flexing their technical skills.
Considering they have been working on it for all these years and have nothing practical to show for it, their technical skills aren't too impressive.
Right, because practical, performant microkernel architectures are so easy that anyone should be able to knock one out in a couple of years. That's why they're so widely used. Those Google guys must be incompetent to have spent almost four years on a new kernel and OS and still not be shipping anything.
Also their design decisions are questionable.
Which decisions are questionable, and why?
Re: (Score:2)
Which decisions are questionable, and why?
Starting off with Microkernel LOL. Why not just use Herd? Might as well add Fuchsia to the OS list [osdev.org]. What problem is solved by Fuchsia that Minix3 doesn't solve?
"Practical performant microkernel" is something that has been researched for over half a century. Anyone who thinks they can just hack around with it and solve the problems that other very smart people have failed to solve is deluded. That kind of problem can be solved, but it will be solved by someone who deeply researches previous microkernels,
Re: (Score:2)
Re: Sounds like marketing or a waste of time (Score:2)
Re: (Score:2)
Then let them answer the question, how have they solved the microkernel problem? I don't care how much experience they have or what credentials they have, but good on them for gaining that experience and those degrees. A degree is not an easy thing to get, after all, and they deserve praise.
Okay, so "make a microkernel" is the only design decision that bothered you.
Re: (Score:2)
Okay, so "make a microkernel" is the only design decision that bothered you.
No, that's not what I said at all. Not even close. It doesn't even bother me that they are making a microkernel. Their approach to making a microkernel is clearly wrong.
Re: (Score:2)
Re: (Score:2)
If Google port the Android APIs to it then it will instantly have a huge library of software available.
This might prove difficult if the new OS isn't POSIX-compatible.
Re: (Score:2)
C'mon!
I for one welcome news of a new experimental OS just as much as I welcome knowing if our future will look trip to Mars will be in the luxury of the Axiom or the nightmare inducing Nostromo.
Just because it could be changing doesn't mean the concept stage isn't interesting and research projects are rarely a true waste of time even if they don't amount directly to a deliverable product.
Re: (Score:2)
I for one welcome news of a new experimental OS
Then you will like this page [osdev.org].
Its a replacement for Linux not Android (Score:2)
Sounds like marketing or a waste of time. Or both.
No, it sounds like a replacement for the Linux kernel. Something that might go into lots of appliances. Including Android. The UI layer may be more speculative but the kernel is actually interesting.
Remember the software life cycle. Eventually a projects gets to the point where it becomes a good idea to toss the existing codebase and rewrite it. Google may be anticipating that point with Linux.
Re:Its a replacement for Linux not Android (Score:5, Insightful)
Sounds like marketing or a waste of time. Or both.
No, it sounds like a replacement for the Linux kernel. Something that might go into lots of appliances. Including Android. The UI layer may be more speculative but the kernel is actually interesting. Remember the software life cycle. Eventually a projects gets to the point where it becomes a good idea to toss the existing codebase and rewrite it. Google may be anticipating that point with Linux.
Speaking from the Android security team's perspective, Linux is perpetually our biggest and most problematic attack surface. A lot has been done to restrict the ways in which malware can poke at the kernel, and actual exploitable kernel compromises (meaning attackers can get through the protections and exploit the kernel) are moderately rare (maybe one per year, or a bit less), but they're so severe that they still make the kernel the most troublesome attack surface.
All of my work is around moving stuff out of Android and into isolated environments (TrustZone, secure elements, etc.) in order to provide some security invariants that hold even if the kernel is popped. If the kernel were more secure, much of what my team does would be unnecessary. However, Fuschia is far from being ready to replace Linux in Android, assuming it ever gets there, and there are no guarantees that if it does it will still be much more secure. Performant microkernel architectures are hard, which is why after over 50 years of experimenting with them we still have no widely-used microkernel-based system.
Spelling "Fuchsia" (Score:2)
Just think of it like "fuck sia"
I'm saying that because no one knows how to spell "fuchsia", I certainly didn't before knowing this trick. ;)
Now, you don't have to copy-paste it to do it
Souce: https://blog.xkcd.com/2010/05/... [xkcd.com]
Re: (Score:2)
Another trick is remembering that the root of the name is the German word "Fuchs" (fox), which is also a German name.
That should be easy enough considering how many people are named Fuchs, even in the US.
Re: (Score:2)
doh.... (Score:4, Interesting)
will only give you control over the targeted components, but they run in independent userland processes, not in the kernel
which was clear after the word "microkernel".
aside from this single feature - where does security come in? Is it a security-first approach like OpenBSD, or is it a traditional OS that simply picked a microkernel and got these specific features for free?
Re: (Score:2)
Is it a security-first approach like OpenBSD, or is it a traditional OS that simply picked a microkernel and got these specific features for free?
IMO after looking at the code, it's very much a "coding style first" approach. The Linux kernel (and other real-world kernels) was too messy for them so they decided to write something cleaner.
Re: (Score:2)
IMO after looking at the code, it's very much a "coding style first" approach. The Linux kernel (and other real-world kernels) was too messy for them so they decided to write something cleaner.
Ah, right. Because readability is the #1 feature every kernel should have.
(don't get me wrong, it's important. Just not #1)
Re: doh.... (Score:2)
Re: (Score:2)
This is the part most people who write comments don't understand. They will write:
# raise index by one
i++;
instead of something like:
# this is NOT an off-by-one error, the index must be one higher than the target field because...
i++;
Whowoodathunkit (Score:2)
Micro kernel? (Score:2)
Fuchsia's micro kernel is called Zircon.
Haven't they Hurd?
Again, it is not clear where Fuchsia is heading (Score:2)
Network stack is difficult but (Score:2)
Everyone always makes a big deal about rooting a device because that is generally where all the exciting unprotected bits are. Microkernels are not ideal in that sense. While you can do things, they are not designed to provide functionality there which really restricts freedom.
On the other hand, the network stack is attractive.
The Fuschi
Re: (Score:2)
The Fuschia network stack is pretty well written. Unlike the trash Linux passes off, the Fuschia stack abstracts buffers and has either good bounds checking or the possibility to implement it system wide with little effort.
What is the performance hit on all that bounds checking and abstraction?