SoylentNews is people
SoylentNews
Proving that the more complex the OS, the easier it is to hack, and how root really isn't required to attack a device a malicious app bypassed Ubuntu Phone security checks to give the attacker full control over the phone.
Luckily only 15 people are known to have downloaded the app but one has to wonder if Ubuntu Phone is already being targeted so successfully in its infancy what does that bode when its a more juicy target?
An educated guess for the unreleased sales statistics can be found on Riccardo Padovani's blog.
This discussion has been archived.
No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
I cannot and will not cut my conscience to fit this year's fashions.
-- Lillian Hellman
(Score: 2, Disagree) by eravnrekaree on Tuesday October 20 2015, @06:50PM
"The more complex an OS is the easier it is to hack" is an incredibly dumb, ignorant and stupid statement that shows fundamental ignorance of how OSs work and how to best protect the system. In fact, an OS with more complexity is far, far more secure than one that is simplistic. I will explain why. MS-DOS is very simple but using it to run a web server is not a great idea because if someone breaks the server, they have complete access to the entire system as the system has no access restrictions at all. By increasing the complexity of the kernel by putting into it sandbox capabilities and system overlay environments, what you do is that while the kernel becomes "more complex" and has more features, in fact, the total amount of critical code that must be absolutely correct. This is done by reducing the kernel attack surface to applications through kernel level features. RBAC and MAC allow for app and user specific security policies to be created and to be easily managed.
A sandbox in its better forms allows you to have a controller program, which does not need to be root, which will be able to intercept all system calls which are made by processes it forks. The forked process has no more access rights than the controller process, and the controller process does not run as root itself, in addition, the controller process can enforce more restrictions on top of that. The controller process can block system calls that a forked process does not need and control access to the filesystem. It can also emulate system calls, all the controller has to do is return values to a forked process that initiated a system call. The controller can issue a system call to the kernel on the forked process behalf, but also can emulate the system call on its own, allowing for lightweight VMs. The controller issues system calls at its own system calls so any access restrictions on the controlled process apply. It is also possible to stack sandboxes, one controller process can be controlled by another controller process. This allows customized sandboxes to be used that strictly control and monitor what an app does and reduces the kernel attack surface.
The second feature is a filesystem overlay. Depending on the configuration of the overlay, Any filesystem writes an app within an overlay makes will not be written to the actual base filesystem but will go into the overlay. This is called an opaque write overlay. This means any changes made by an installer could be easily removed by simply deleting the overlay, the overlay can also monitor exactly what an app tries to do. An overlay can be configured on a rule based system, so that for instance, write access could go to the overlay in certain areas of the filesystem but could go to the base filesystem in others, and as well, read access to the base filesystem can be blocked in some areas and allowed in others. Overlays can be implemented on top of the aforementioned sandbox so this feature does not need to go directly in the kernel, necessarily. You might want to give an app base filesystem access only for a directory specifically for the storing files created by the app for sharing with other apps, and otherwise confine it to the overlay for everything else. In addition, it serves to provide RBAC and MAC read access blocking to large areas of the base filesystem the app does not need. This means blocking /etc, /home/ etc, except for the apps own config files, for instance.
While the kernel has more features and more code, its easier to audit that block of kernel code than it is to audit the thousands of applications that would run on it. There is far, far more app code than there is code in the kernel for these particular features. The result of this is that a while the kernel has more features, the overall amount of code that absolutely must be correct is smaller. The application can have serious security problem but it can be contained within its sandboxes and overlays. In many respects, the older DAC Unix security model and "use root for all things administrative" has serious, awful problems. Add to that all kinds of sheer absolute stupidity such as forcing e-mail and web servers to run as root becuase only root can open low port numbers. In addition you have such flat mindedness such as giving installers, via root, complete acces to the entire filesystem when they only need to install 1 program at very specific locations.
This all being said, the Unix idea of not putting GUI into the kernel and putting more complex stuff in userland programs is smart so there is a lot of stuff you dont want in the kernel. In fact, The sandbox and overlay features allow the complex userland programs to be contained in safe boxes. The sandbox controller process model actually puts minimal code in the kernel, most of the policy code is in a userland app.
(Score: 0) by Anonymous Coward on Tuesday October 20 2015, @07:02PM
tl;dr
(Score: 1, Insightful) by Anonymous Coward on Tuesday October 20 2015, @09:25PM
It seems you you are passionate about this, but saying that it "is an incredibly dumb, ignorant and stupid statement that shows fundamental ignorance of how OSs work and how to best protect the system." is fucking rude as fuck. Yes, ignorant perhaps, but dumb and stupid? Fuck off.
(Score: 2) by DeathMonkey on Tuesday October 20 2015, @09:26PM
less complex != more secure
True, perhaps. However, less complex is definitely easier to secure.
(Score: 0) by Anonymous Coward on Tuesday October 20 2015, @11:35PM
As MICROS~1 has demonstrated repeatedly with its ridiculous time-to-patch performance, [google.com] the more complex the interactions of your code, the longer it takes to check that fixing 1 thing doesn't break 20 other things.
In contrast, having code that does 1 thing, does it well, and interacts predictably with other code built to the same standard [wikipedia.org] makes life much easier when a patch is needed.
-- gewg_
(Score: 2) by Runaway1956 on Wednesday October 21 2015, @12:53AM
You've heard the engineering maxim? KISS - Keep It Simple Stupid. The more complex anything is, the more things there are to go wrong. And, in the case of operating systems, the more complexity there is, the more potential exploits there are. An OS is going to be pretty complex, even when the coders shoot for simple. But the maxim dictates that they introduce no more complexity than necessary.