161–170 of 172 posts
So I'm not clear what the puropse of fuchsia is. I understand it's an os which may replace android or chomeos but why the move away from linux based systems? Both are open source platforms.
We probably need open source hardware for this to go away and to be free.
Except you can't sandbox or virtualize the clock because mx_time_get() doesn't require a handle, which makes timing attacks easier. You also can't sandbox event and channel creation for the same reason. It looks like these can also DoS the kernel. In general, any operation you can perform without a handle tends to be subject to DoS and you can't virtualize it. They're also subject to a different access control policy…
I'd be interested if this has been brought up with the dev team via IRC, mailing list, or some other medium so they can explain their reasoning?
Earlier quoted context omitted.
"You can literally go and compile the entire kernel, right now." Android discussions started that way. Things changed after enough time and revenue with a huge gap between ASOP and Android experience. Their security fixes vs Apple are also now abysmal. Might be a hint at the future of Google's next OS.
"Things changed after enough time and revenue with a huge gap between ASOP and Android experience." No, things changed for other vendors and for other parts . You can, AFAIK, still happily compile Google's entire kernels. You are thinking of userspace.
Is it really Android advertised to the West that people want if it doesn't have the userspace? That's like Windows open-sourcing the kernel but all the needed apps are proprietary. Might as well consider the overall thing proprietary unless your customers exclusively want the kernel plus also-ran software.
Earlier quoted context omitted.
Why am I not surprised that you can't even get your percentages correct.
Sorry, unfortunately I did get my numbers wrong. Based on a chart of Android versions taken from the Google site, it will probably be at least a month or two before 0.7% of Androids are running the latest version. My bad! I keep a running copy of the stats here: https://oasis.sandstorm.io/shared/UtPbpOAW2OaV4QpkgwIclqGeGC...
Earlier quoted context omitted.
>Android has inherited all of that and it's by far the shittiest mobile OS out there in terms of how easy it is to own. Then why don't you try? Google has $200,000 USD waiting for you to exploit a fully patched Pixel. Or are you too rich to make it worth your while? If you're going to say something that silly at least have the technical prowess to walk the talk.
First, is there a point that you are trying to make because I didn't see any. Second, 200k USD for a vulnerability of such caliber is peanuts. Third, you must have missed this: http://blog.trendmicro.com/results-mobile-pwn2own-2016/
https://www.youtube.com/watch?v=Zm6ziX5pqt8
>Second, 200k USD for a vulnerability of such caliber is peanuts.
I think that's the going rate offered by companies that buy exploits like Zerodium. Do you know of a company offering a better price?
>Third, you must have missed this: http://blog.trendmicro.com/results-mobile-pwn2own-2016/
First, the hack was impressive because of all of the exploits they had to chain. Perhaps this gives you an understanding of just how difficult it really is and why I called your comments regarding Android security silly. Secondly, I don't believe their hack was possible via RCE and needed physical access to the device. Third, you neglected to mention that not only was the iPhone hacked, but it was done so twice. Additionally, the 2 iPhone hacks earned more money than the Nexus 6P hack. Did you also want to comment on the state of iOS security?
Earlier quoted context omitted.
First, is there a point that you are trying to make because I didn't see any. Second, 200k USD for a vulnerability of such caliber is peanuts. Third, you must have missed this: http://blog.trendmicro.com/results-mobile-pwn2own-2016/
I think my point is pretty clear - your comments regarding the state of Android security are very lacking. I suggest you watch this video by Adrian Ludwig at Next 2017 for an overview: https://www.youtube.com/watch?v=Zm6ziX5pqt8 >Second, 200k USD for a vulnerability of such caliber is peanuts. I think that's the going rate offered by companies that buy exploits like Zerodium. Do you know of a company offering a bette…
None of that takes place in the public eye, but of course one can figure some of it out if one pays attention. In some cases, one can also extrapolate what the state of this "underground" is by examining the research that does become public.
Earlier quoted context omitted.
I think my point is pretty clear - your comments regarding the state of Android security are very lacking. I suggest you watch this video by Adrian Ludwig at Next 2017 for an overview: https://www.youtube.com/watch?v=Zm6ziX5pqt8 >Second, 200k USD for a vulnerability of such caliber is peanuts. I think that's the going rate offered by companies that buy exploits like Zerodium. Do you know of a company offering a bette…
You have little understanding of this space, as evident by your comments re: Zerodium. Allow me to inform you that there are plenty of buyers that are willing to pay top dollar for such exploits, as are plenty of people that keep such exploits to themselves or sell them to buyers that will not disclose them. None of that takes place in the public eye, but of course one can figure some of it out if one pays attention.…
Except you can't sandbox or virtualize the clock because mx_time_get() doesn't require a handle, which makes timing attacks easier. You also can't sandbox event and channel creation for the same reason. It looks like these can also DoS the kernel. In general, any operation you can perform without a handle tends to be subject to DoS and you can't virtualize it. They're also subject to a different access control policy…
There are mechanisms in the works to allow the VDSO to be customized per-Job along similar lines (providing a way of addressing mx_time_get(), etc). mx_time_get() is actually provided entirely in userspace in the default VDSO, but of course we want to allow for runtime environments where we don't allow direct access to the TSC or equivalent.
There aren't any "known" handles in the Magenta design, as handles are not small integers nor aggressively reused (as fds are in unixen). The intention there is to make use-after-free errors with handles more difficult and to make guessing what handles a process has harder.
It's definitely not a "pure" capability design or a "pure" (read/write/exit) microkernel underneath. The goal is to try to be pragmatic and balance performance and api usability/convenience with the benefits of a capability system.
It's also a system in development and the shape of things has changed and almost certainly will change further before we're done.
Except you can't sandbox or virtualize the clock because mx_time_get() doesn't require a handle, which makes timing attacks easier. You also can't sandbox event and channel creation for the same reason. It looks like these can also DoS the kernel. In general, any operation you can perform without a handle tends to be subject to DoS and you can't virtualize it. They're also subject to a different access control policy…
The creation syscalls operated under the execution constraints of the Job in which your Process is contained. The APIs aren't fully landed, but it will (very soon) be possible to create Jobs where-in none of the kernel object creation syscalls will be allowed. You can think of the creation syscalls as taking an implied handle to the Process's Job, which is an "object factory" similar to what you suggest. There are me…
Implicit handles are not explicit handles, and capability security requires explicit handles. You're obviously familiar with capabilities and the problems inherent to breaking capability properties, so why violate them in this instance?
You mention API usability, but mx_get_time() and mx_get_time(clock_sys), where clock_sys is a static variable initialized by the runtime library at start isn't really any more unusable. Like printf, you can even wrap it in more convenient procedures with no parameters, but you can't go the other way and reify to the clock if that's not how it's designed to begin with.
> There are mechanisms in the works to allow the VDSO to be customized per-Job along similar lines (providing a way of addressing mx_time_get(), etc). mx_time_get() is actually provided entirely in userspace in the default VDSO
This is exactly what I was talking about though: it's totally unnecessary if the clock were accessed via a handle. Why build all of this extra infrastructure when it's completely unnecessary?
Every process would get a set of handles for its basic services, like clock, scratch folder, what-have-you, and building an isolated process just replaces the system handles with wrapped ones. What's the deficiency in this approach that you'd decided to build a more complicated infrastructure instead?
> The intention there is [...] to make guessing what handles a process has harder.
I'm not sure what the point of this is. Are handles not partitioned/per-process like file descriptors? Knowing what file descriptors another process has doesn't give you access to them or yield any advantages. This is how object capabilities should work.
Earlier quoted context omitted.
The creation syscalls operated under the execution constraints of the Job in which your Process is contained. The APIs aren't fully landed, but it will (very soon) be possible to create Jobs where-in none of the kernel object creation syscalls will be allowed. You can think of the creation syscalls as taking an implied handle to the Process's Job, which is an "object factory" similar to what you suggest. There are me…
> You can think of the creation syscalls as taking an implied handle to the Process's Job, which is an "object factory" similar to what you suggest. Implicit handles are not explicit handles, and capability security requires explicit handles. You're obviously familiar with capabilities and the problems inherent to breaking capability properties, so why violate them in this instance? You mention API usability, but mx_…
Having them be harder to guess provides some (minor) additional defense against attempting to remotely exploit bugs in another process.