4 ms·

I'm quite scared, that they will in fact introduce so called "Rootless" kernel-level security - not beeing able to do everything with my computer would be a pro

I'm quite scared, that they will in fact introduce so called "Rootless" kernel-level security - not beeing able to do everything with my computer would be a problem for me and I will definitelly consider switching to ie. Dell XPS with some linux on board.

jbrooksuk 11y ago
Supposedly it'll be configurable on OSX.
- MCRed 11y ago
  It would be very out of character of Apple if it weren't configurable. Yes, iOS is secure, but OS X has always been more open in this regard and there's really no reason to believe that they won't continue this trend. After all, when they introduced App signing they could have made it so the mac would only run signed apps. Of course they didn't do this.
- mlitwiniuk 11y ago
  Supposedly that possible, but the real question is, if this still will be the case in 10.12? This concern was posted by someone somewhere few versions back, when they introduced code signing explicite allowance for apps not signed properly. This is next step. And as long, as I agree - security is important, judging on their past decisions, they may try to close their ecosystem (but hey, it's "their" hardware and software, their game and their rules - one can always decide not to buy Apple anymoe).
danpalmer 11y ago
This will be configurable, if only because Apple need developers in their ecosystem, and many developers won't be able to do their jobs on a machine they don't have full access to.
mrsteveman1 11y ago
When I read the rumors about it (which are mostly speculation), I essentially expect them to do the following (on OS X at least): A) Make the Apple-provided system files read-only, maybe even put them on another read-only partition like iOS does. They explicitly said[1] they were locking down system files 2 years ago at WWDC 2013: "in the future as we start to lock down the /System folder, you might actually get write errors.". As /System is already owned by root, write errors at /System means elevating to root won't be enough. B) Assuming "rootless" is in fact a superset of what I mentioned in A, and going by the rumored name, they could be restricting what the 'root' user can do by default on OS X, matching some configurations of Linux where simply gaining root access doesn't automatically gain you total access. In other words, root can do things like load signed kexts, install system-wide software, etc, but not overwrite critical system files or perform various other sensitive actions that shouldn't be possible just by entering an admin password (which a LOT of software packages require during installation). edit: also, they did include Hypervisor.Framework in 10.10 which is a significant engineering investment but doesn't seem to have a purpose at the moment (major virtualization vendors aren't likely to use it, neither are app developers. That leaves Apple...). I honestly wonder if they're planning to use it for security purposes in 10.11+. They did something similar with XPC, introducing it for use by developers first, and then in 10.10 they started using it extensively to isolate things in the OS (including Extensions). [1] http://asciiwwdc.com/2013/sessions/707 http://asciiwwdc.com/2013/sessions/707

jbrooksuk 11y ago

Supposedly it'll be configurable on OSX.

MCRed 11y ago
It would be very out of character of Apple if it weren't configurable. Yes, iOS is secure, but OS X has always been more open in this regard and there's really no reason to believe that they won't continue this trend. After all, when they introduced App signing they could have made it so the mac would only run signed apps. Of course they didn't do this.
mlitwiniuk 11y ago
Supposedly that possible, but the real question is, if this still will be the case in 10.12? This concern was posted by someone somewhere few versions back, when they introduced code signing explicite allowance for apps not signed properly. This is next step. And as long, as I agree - security is important, judging on their past decisions, they may try to close their ecosystem (but hey, it's "their" hardware and software, their game and their rules - one can always decide not to buy Apple anymoe).

danpalmer 11y ago

This will be configurable, if only because Apple need developers in their ecosystem, and many developers won't be able to do their jobs on a machine they don't have full access to.

mrsteveman1 11y ago

When I read the rumors about it (which are mostly speculation), I essentially expect them to do the following (on OS X at least): A) Make the Apple-provided system files read-only, maybe even put them on another read-only partition like iOS does. They explicitly said[1] they were locking down system files 2 years ago at WWDC 2013: "in the future as we start to lock down the /System folder, you might actually get write errors.". As /System is already owned by root, write errors at /System means elevating to root won't be enough. B) Assuming "rootless" is in fact a superset of what I mentioned in A, and going by the rumored name, they could be restricting what the 'root' user can do by default on OS X, matching some configurations of Linux where simply gaining root access doesn't automatically gain you total access. In other words, root can do things like load signed kexts, install system-wide software, etc, but not overwrite critical system files or perform various other sensitive actions that shouldn't be possible just by entering an admin password (which a LOT of software packages require during installation). edit: also, they did include Hypervisor.Framework in 10.10 which is a significant engineering investment but doesn't seem to have a purpose at the moment (major virtualization vendors aren't likely to use it, neither are app developers. That leaves Apple...). I honestly wonder if they're planning to use it for security purposes in 10.11+. They did something similar with XPC, introducing it for use by developers first, and then in 10.10 they started using it extensively to isolate things in the OS (including Extensions). [1] http://asciiwwdc.com/2013/sessions/707 http://asciiwwdc.com/2013/sessions/707