Gaining a Remote Shell On Android 124
SharkLaser writes "The security of Android devices has come under scrutiny in recent months. Android Market has been plagued with a number of trojaned apps, and researchers have identified various root exploits and permission leaks that can be exploited, for example, to send premium rate SMSs. Now researcher Thomas Cannon of ViaForensics is demonstrating a method for setting up remote shell on an Android device without using any exploits or vulnerabilities. The security hole is not new, and it has been pointed out for a number of years, but Google has yet to fix it. The method works on various versions of Android, up to and including the newest Ice Cream Sandwich."
Direct link to Vimeo How-To (Score:5, Informative)
Re: (Score:3)
Is this the iphone that was rooted by downloading a PDF?
You must be referring to the two exploits in the previous version of iOS that were quickly patched. Apparently Apple has trouble porting functionality to subsequent versions of iOS. Who says Apple can't learn anything from Google?
_NSAShell (Score:3, Interesting)
Why do these tinfoil hat types keep bringing up the _NSAShell functionality? Enough already!
Re: (Score:1)
> Why do these tinfoil hat types keep bringing up the _NSAShell functionality? Enough already!
Because it hasn't been patched yet, and because it's a significant vulnerability.
Clear enough?
Re: (Score:1)
Re: (Score:2)
TFA is blank (Score:2, Interesting)
Re:TFA is blank (Score:5, Informative)
No-permission Android App Gives Remote Shell
I have been working at viaForensics as the Director of R&D for about 5 months now, and in that time I’ve been involved in some exciting research projects. I haven’t had the opportunity to blog on our company site yet so I thought I’d take a little time out and record a video to demonstrate an Android issue that is of interest to many of our clients.
When talking with people and reading posts on the web I’ve often heard people say that the Android permission system protects their device such that apps without certain permissions are therefore safe to install. The permissions system on Android is a fantastic idea and generally well implemented, it gives apps just enough permissions or capabilities to perform the required functions without exposing capabilities that could be used in a dangerous way. It is a step up in protection when compared with a typical desktop system but this increased protection can give rise to a false sense of security.
Putting aside the issue of users ignoring the permissions when installing apps, can we rely solely on permissions to decide if an app is safe? There are multiple controls in Android and its ecosystem that protect a user and their device, but one should not automatically assume that installing an app, even if it requires no permissions, is safe.
To demonstrate this we’ve built an app which requires no permissions and yet is able to give an attacker a remote shell and allow them to execute commands on the device remotely from anywhere in the world. The functionality we are exploiting to do this is not new, it has been quietly pointed out for a number of years, and was explained in depth at Defcon 18 [1]. It is not a zero-day exploit or a root exploit. We are using Android the way it was designed to work, but in a clever way in order to establish a 2-way communication channel. This has been tested on Android versions ranging from 1.5 up to 4.0 Ice Cream Sandwich, and it works in a similar way on all platforms.
Please see the video below with accompanying audio for further explanation.
Link to video: Android No-permissions Reverse Shell
I should also mention here a recent paper by Michael Grace, Yajin Zhou, Zhi Wang, and Xuxian Jiang from NCSU who have developed a tool to detect capability leaks in Android devices. Using their tool they found a number of capability leaks, such as being able to send an SMS, in various Android applications usually added by OEMs. Malicious applications can call the vulnerable apps and exploit the lack of protection around permission/capability use and therefore do not need to request permissions themselves. In a similar way we’ve exploited the Android Web Browser, although we are not exploiting a vulnerability due to bad coding, but rather using the functionality it legitimately offers to other applications.
In this demonstration Android’s power and flexibility were perhaps also its downfall. Other smartphone platforms may not offer the controls we are bypassing at all, and the multi-tasking capabilities in Android allowed us to run the attack almost transparently to the user. This power combined with the open nature of Android also facilitates the customisation of the system to meet bespoke security requirements. This is something we have even been involved in ourselves by implementing a proof of concept Loadable Kernel Module to pro-actively monitor and defend a client’s intellectual property as it passed through their devices. It is no surprise that we have seen adoption of Android research projects in the military and government as it can be enhanced and adapted for specific security requirements, perhaps like no other mobile platform before it.
I hope this demo was of interest and that it generates some discussion around the best ways to select and use apps which offer the least risk to your device and data.
Update 20-Dec-2011: As mentioned these issues are not new and have been discussed before
Re:TFA is blank (Score:4, Insightful)
Amazing web page. A security page that requires javascript to display. If you look at the source, the entire readable content a dozen short paragraphs at the end, each written on one line, and being mere verbaige around the real content, which is a video hosted elsewhere.
Somehow I don't think I'll be taking any of this site's suggestions very seriously.
Re: (Score:1)
Sorry, clicked wrong while moderating the post.
Re: (Score:2)
I use Noscript. Why should I trust some unknown web site to have good intentions and good skills? Further, almost all javascript I have seen is only used to track me or play with the ads.
No thank you. My screen, my rules.
Re: (Score:2, Insightful)
Re: (Score:1)
( signed, a guy who uses his ancient phone just to make calls and take the occasional low-res video )
Re: (Score:1)
Yes, it's perfectly reasonable to expect users to install and configure iptables on their cell phones. We know this because you wrote "easily" twice!
Re: (Score:2)
If leaving out the rooting part... (what is app install from market + single click to root/unroot) the iptables is easy to use in Android
1. Install droidwall (or any other iptables firewall)
2. Start application and check/uncheck applications rights to have connection when in 2G/3G or WiFi mode.
I hope it would be as easy with Linux distributions....
Re:Firewall (Score:4, Interesting)
Re: (Score:2)
Easily defeated by a firewall like iptables, which can be easily installed from the market if you have root.
I am not so sure about that. In this case the actual exploit was using the built in web browser to talk to the internet so surely the only way you could block this with iptables is to block your phones default web browser from accessing the internet, surely that is not a great fix.
Re: (Score:1)
Practicality is not a hallmark of Android defenders.
No vulnerabilities? (Score:5, Informative)
Unintended root access is a vulnerability by definition.
Re:No vulnerabilities? (Score:5, Informative)
This doesn't give root, it just allows you to run a command within the context of the installed app. The app launches the web browser to pass data to and from a middleware server. So if the app itself doesn't have any specific access (including network access) it can still transfer data through launching a browser session.
It's more of a conscious decision by the android team. If you allow an application to launch an URL, then of course it can transfer data through the http session. However not allowing apps to launch a simple URL link would be very limiting, so they chose not to do that. I'm not sure there's a fix really, as this is a classic security / convenience problem.
Re:No vulnerabilities? (Score:5, Interesting)
Re:No vulnerabilities? (Score:5, Interesting)
Interestingly enough, you get something of a kind if you install more than one browser on your phone - then, whenever a link is opened by an app, you'll get a dialog prompting you to select the browser to use for this protocol henceforth (and a checkbox to not ask again).
Unfortunately, the setting isn't per-app, so not as useful. Still, can be a handy trick for the more paranoid (but then they're probably using N900, anyway).
Re:No vulnerabilities? (Score:4, Informative)
This doesn't give root, it just allows you to run a command within the context of the installed app.
How many times do we need to revisit the MS Word VBScript virus problem before we learn from it?
Here are some obligatory automatic security fails (on any platform) that guarantee your wonderfully architected system will be oft and immediately bypassed:
1. Asking the user to decide. Users don't read dialog boxes and just click/tap to make them go away. They will often happily answer YES to the "Install unsigned ActiveX control" dialog so they can see the dancing monkey or play some game. How often do you think they will pay attention to what rights an app wants and make a reasoned decision about whether that is a good idea or not? (Hint: almost never)
2. Asking the developers to oh-so-politely make sure they use best-practices and don't have any exploits or holes. They can and will not only willfully ignore your security best-practices but in fact will go out of their way to hijack the system because *their* app is special and like totally has a really good reason for it man! (See apps that hijack the right-click menu/sys tray/startup group/install 15 services/drivers that all auto-start/etc on Windows and the awful state of many drivers).
3. Assuming that an app should be able to do what the user can do - Granted this is not a problem with a sandbox system but still... Apps can't be trusted. Even when there is no ill intent there can still be unintended exploits (or just bad designs like running in the background constantly draining the battery when not necessary - part of the reason iOS still doesn't let apps run continuously unless they have an explicit reason like audio playback).
4. Assuming the user has the time or a f**k to give. In most cases the computer, phone, etc is just an appliance and they don't know or care about automatic updates, patches, security, etc. They just want the damn thing to work and stop annoying them. After all... most dangerous things have warnings and/or safety features and don't require you to check the manufacturer's website on a daily/weekly basis to see what new way to kill yourself has popped up. It can be impossible to keep up with even for technically-minded people who happen to have busy lives.
Re: (Score:2)
I actually do this: I make all the "best" security decisions default, and automatically applied.
Misbehaving apps in my scripting environment (well, user generated mods for a game engine) simply fail with an error message:
"Script Error: #42. - Returning to main menu."
If a user wants to be able to see those detailed dialogs such as:
"Script Permission Error #42: MOD attempted a to connect to a domain not in your trust list.
[T]rust: some.questionable.site.com [
Re: (Score:2)
> It's more of a conscious decision by the android team.
And what makes them decide this for me? Shouldn't this be a permission like so many other features of Android? I am asked whether I grant network access, and calling URLs should be pretty much the same.
Re: (Score:2)
Re: (Score:1)
In that case it's lucky the method in the article doesn't gain root access, and can do nothing beyond what the "shell proxy" app can do.
Re:No vulnerabilities? (Score:5, Informative)
Re: (Score:3)
A shell which provides a convenient attack vector for root access if and when a vulnerability is discovered/crafted.
Re:No vulnerabilities? (Score:4, Informative)
Even in that case the shell is ridiculously restricted on Android. You can't even run sqlite command from the app.
Re: (Score:2)
and the point really here is that it goes around network capability.
so you can have an app that's not supposed to connect to the net make a connection and run things in linux side, even if just in it's own process.
and you can run sqlite on phones where the commandline sqlite app isn't removed by the oem, it is there in some models - but you can put it there, if it happens through having a shell or a program that takes in code and runs it is rather irrelevant though(well, what is a shell anyways..).
but there
Re: (Score:2)
You're missing the point. If a new 0-day vulnerability is discovered tomorrow, you can write a new program to exploit it, or you can use your existing install base to deliver the payload without any new action on the part of the users/owners. Remote access to a system increases its attack surface. It's *always* a security risk, and it's only irrelevant until it bites you in the ass.
Re: (Score:2)
Re: (Score:2)
Or Just a Local Shell (Score:5, Insightful)
Until my phone's Android lets me run the Android Perl shell app on it without rooting, it's not "open", no matter what Google says. The source code might be open, at least "open readonly", and the binary might be "open execute" by hackers onto unauthorized hardware. But the OS instance is not open if it's not open to me as a user to invoke its API with an app that can do the job.
Re: (Score:3, Funny)
Re: (Score:2)
I also can't use apt-get on Ubuntu unless I'm root. So... would that also make Ubuntu "not open" by your definition? Plenty of other things I can't do without root in Linux.
Do not confuse "security" with "closed." Don't know anything about the app you reference, but I'm guessing it requires privileges not normally granted to a user-installed app. For security reasons. That's pretty common to Linux in general.
Re: (Score:2)
You're right, right up to the point where you are 100% wrong.
The difference between Android running on a Phone and Ubuntu running on your Computer, is that with Ubuntu, you probably have ROOT control, even if you have to grant it to yourself *sudo", and type a password, to do it. On Android, you don't even have that ability ... by default.
Re: (Score:1)
I hope you ignite yourself when you burn those straw men.
Re: (Score:2)
You're right, right up to the point where you are 100% wrong.
The difference between Android running on a Phone and Ubuntu running on your Computer, is that with Ubuntu, you probably have ROOT control, even if you have to grant it to yourself *sudo", and type a password, to do it. On Android, you don't even have that ability ... by default.
Actually, on at least one of my android devices I do have root permission just by doing some equivalent of sudo. That is the one I have reflashed with Cryanomod. It is still Android though.
But Oh, you were talking about the commercial devices produced by Motorola, HTC and the like? These companies have made a choice to close their devices and remove something that Android can easily do, but that is not Andoid, that is whoever produces the locked down device.
Re: (Score:2)
So Motorola/HTC/etc are the ones who closed the Android instance on the phone. That doesn't argue that it's open, it explains how it is closed, which therefore agrees that it's closed.
I'm not talking about who's to blame, I'm talking about the condition of the OS instance on the phone, the inarguable reality for most people.
Re: (Score:2)
If you were the owner of the Ubuntu machine, and no other person had the root password, it would not be open. That is the situation with Android.
Re: (Score:2)
Re: (Score:2)
Are you talking about an existing "Android Perl" app that requires root permissions? Do you have a link?
I don't see why you'd need root access. You can download one of the terminal emulator apps and run anything within the context of the app.
You may need to figure out how to get it compiled, though.
Re: (Score:2)
Running the Terminal Emulator shell app gives "permission denied" to any invocation of any executable or attempt to read any dir or file. Maybe rooting the phone before installing it would help, but that's my point about how the OS is not open.
Re: (Score:3)
If rooting consisted of entering "su" in a console and then typing your password/PIN or whatever, I'd agree with you - but have you seen the hoops some users have to jump through to get root on their Android devices?
Re: (Score:1)
You are an idiot of the first order.
If you have shell access on a Linux server, but not root, does that mean that the source is no longer open? Google never promised that the system would be "open", only that they would provide source for anything based on Open Source.
Re: (Score:2)
A machine that I own and use that doesn't allow me root access is not open. If I have to reinstall or otherwise hack the OS to be granted root access, then the OS is not open - I had to open it, despite the OS.
Re: (Score:2)
Ah, but there's a key difference - if you own that Linux server, you will most certainly be able to get root access.
Even if you own your phone, that's not always the case.
This isn't even close to new (Score:4, Insightful)
Not new, but scary! (Score:3)
Right, big deal, the app calls the browser to do something in the background while the screen is locked. However, you may be scared after reading the following PDF Systematic Detection of Capability Leaks in Stock Android Smartphones [google.com] -- I was!
Jump to page 9 for the table.
Three HTC phones allow rouge apps (without the defined permissions) to record phone calls and send SMS! The SMS example is neat as they broadcast an intent with the phone number in it; then stock apps on the phones actually send the messa
Re: (Score:2)
well, the "big" thing here is really that browser doesn't need NETWORK capability.
a little off topic but,,, (Score:1, Offtopic)
what is the best way to install vim to my android?
TIA
it is not root access (Score:5, Informative)
What happening here is that the app he installed opens the web browser to when you lock the screen. The app is then, in here in lies the secret sauce, is able to get the commands from the the browser is receiving. The browser part is simple, it can poll looking for input. How the app gets that input is interesting part. I don't know how its doing that. It may have created a callback from the browser to there app. Android has excellent inter process communication tools, but I don't know how he is doing this from an app he doesn't control. I've only thought about it for 5 minutes though. With this app and another app you control, this exploit would be trivial (one with internet access and another with sdcard access for example). I think any app can execute process with would give it access to the shell. That doesn't mean it has root access, but Android will let you view much of the file system without root. You cannot get to private app data storage, but you can see the sdcard and other basic parts of the file system like /framework or /etc.
http://developer.android.com/reference/android/os/Parcel.html [android.com] this shows inter-process communication.
http://developer.android.com/reference/android/content/Intent.html [android.com] this shows how to launch the browser.
Re: (Score:3)
Yup, so basically "gaining a shell" is not at all interesting here, since it doesn't let you do anything the app can't otherwise do. The real gem is being able to do network communications without requesting the appropriate permission for your sandbox when installing.
Re:it is not root access (Score:5, Informative)
The magic is getting the browser to return its data back to the app without privileges. That turns out to not be hard either. I found an example and posted it below. With this, you have a functional two way link from app without privileges to webserver and back. I'm not impressed and I don't consider this an "exploit". If you want a system that allows apps to communicate with each other, which we all do, then you have to be careful of what you install on your phone. This is better than a PC which almost always has full root access. This is just voyeur access...
http://www.android10.org/index.php/forums/49-other-coding-problemsarticles/1575-example-communication-between-an-activity-and-the-browser-callback [android10.org]
Re: (Score:2)
It is an exploit in a sense that Android does have a "permission to use networking" for apps, and if I install the app that does not have such a permission in the Market, it shouldn't have network access.
You've got a point regarding inter-app communication. Perhaps that should be a separate permission; or, better yet, prompt it whenever the app tries it (though then the app could just open some kind of "about" page in the browser on first launch, user gives it permission... and then it does the whole thing
Re: (Score:2)
I'd support a permission for launching intents originating outside this signed package. Starting an Activity, like a new screen in the current app uses the same code as starting the browser or any other activity. If Android is able to tease apart the difference, and I think that would be possible, then that seems reasonable. I have an app that launches a service for listening for an Accessory (ADK) mode device that is outside the original package because ADK requires Android 2.3.4 but the app only requires
Re: (Score:2)
well, install opera, when it asks you which browser to use to fill a browser opening request, choose opera and don't tick the box to open it always if you think it might work through opera too.
anyhow. on maybe 80%+ of android phones, if you get shell access you can run some exploits to get root access.
Why does Android forbid root to the owner? (Score:5, Insightful)
This is a question which doesn't seem to get asked much, probably because Google is an unmovable behemoth that's not really interested in the owners of devices, but only in advertisers. Nevertheless, it needs to be asked.
These cellphones and tablets belong to us, they don't belong to the device manufacturer, nor to the cellphone service operator, and even less to Google. They are ours. So why are we, the owners, forbidden direct root access to our own devices? It's like owning a Linux desktop without root, or owning a Windows machine and not being allowed Administrator access.
It's daft, and it's completely wrong.
Currently the crackers seem to have easier access to root than the device owners. Google, stop navel gazing and caring only about profit, and do something for users for a change. Add to standard Android a legitimate method for users to have access to root on their own devices, so that "rooting" becomes a thing of the past. It's not your right (nor anyone else's) to deny it.
Morgaine.
Re: (Score:1)
good rant.
It's just a pity that it's 100% factually incorrect.
Re: (Score:2)
Google didn't lock down your streak - Dell did. Same thing goes for the Archos thing... next time, buy Nexus or research properly (whether or not a viable root method is available for the device you intend to buy) before purchasing.
Of course, (IMO) this situation shouldn't exist in the first place - Google shouldn't be allowing carriers and manufacturers to lock down phones this way at all... but that's a different topic. :(
Re: (Score:2, Informative)
It's like owning a Linux desktop without root, or owning a Windows machine and not being allowed Administrator access.
Uh, 'Secure Boot', dude. With Windows 8 you will only have whatever control Microsoft allow you over the Windows computer you thought you owned... if they disable admin access in Windows 9, you won't be able to patch the loader to re-enable it because it will refuse to run.
What are you smoking buddy? (Score:3)
"Secure Boot" is nothing new. They had that over ten years ago in their xbox game consoles. Its a simple chain of trust where the OS is loaded in a modular approach starting with the BIOS/UEFI handing off control to the next link only after cryptographically verifying their signatures. It has nothing to do with "locking" you out. Its a method to be reasonably sure that the OS is not compromised w/o hardware access (disabling secure boot is a bios option IIRC). If they wanted to lock you out from admin, the
Re: (Score:2)
This is a question which doesn't seem to get asked much, probably because Google is an unmovable behemoth that's not really interested in the owners of devices, but only in advertisers. Nevertheless, it needs to be asked.
For years we've been saying that local users should never operate as administrator by default. Now someone is doing it, you're getting pissy? Double standards much.
Besides this Google has answered it. Root should be as simple as SU.
The enforcement of non-admin privileges is done by the Android manufacturer, they do it because the carriers demand it. Want to stop it, stop buying phones from the carriers and make sure they know.
Re: (Score:2)
While I agree with your premise somewhat, you're confusing a few things.
Google's phones (Nexus) are all easily unlockable and rootable. That's no accident...
The problem is the carriers and manufacturers, who just love locking down their phones to turn them into featurephones with apps... no doubt, Google should be looking for a way to force complete openness on both the carriers and the manufacturers, but it looks like that might be far easier said than done...
Now if only Google would release Motorola's nex
Re: (Score:1)
There are many phones what are easily rootable. Depending the country where you live.
Example all Android phones in my country are unlocked to carrier and SIM. So you can do what every you want with them. Rooting phone is just installing root application and pushing button.
And user does not even void varranty because that unless problem is caused by software. (if your MicroUSB plug brokes so you dont get good connection, it does not matter if you have third party ROM installed. But if your CPU burns and they
Re: (Score:2)
It's like owning a Linux desktop without root, or owning a Windows machine and not being allowed Administrator access.
. . . which is why I bought a Nokia N9 with Meego Linux. Do you want root access? Switch on "Developer Mode", which warns you of the risks, and you must press "Accept".
. . . and this is why I will (hopefully) buy a Tizen device in the future. A post recently to the Tizen mailing list stated something like, "This will be a real Linux distro, where you can do anything, not like Android."
There is no reason to whine, moan and complain that you have to jailbreak Android for root access. This is already wel
Re: (Score:1)
. . . which is why I bought a Nokia N9 with Meego Linux.
N9 comes with Harmattan aka Maemo 6.0.
MeeGo is Maemo 5.0 + Moblin 1.1
Harmattan is not 100% compatible with MeeGo and almost only way is to use pure Qt in your applications and even then repackage your software to RPM and DEB to deliver both.
Even Nokia developers needed to explain that Harmattan != MeeGo but it is just a marketing....
Re: (Score:2)
Check out the actual Google Nexus line of phones, and you can get root with a simple command--basically "gimme root". No hacks required.
Erm (Score:1)
Couldn't find anything mentioned in this thread about how it was the _simulator_ he was demoing, not an actual device... Big difference.
Re: (Score:2)
The simulator was for ease of recording the video, not because that's the only place it was tested.
I find this to be a good thing (Score:3)
Shockingly, because Mac users were so damn gung ho on how absolutely secure their OS was, there was an over 90% installation rate. 40% used the application more than once. It took 6 weeks for the app to be taken down... and people were still downloading it even though the comments screamed about how it was a virus.
Microsoft Windows 7 is EXTREMELY secure now because of several things...
1) People DON'T trust Windows apps like the used to... they're skeptical about viruses.
2) People run anti-virus software... which may be useless on zero-day bugs and often can be more harmful to the user experience than any virus they can block, but they run it.
3) Microsoft bought a gazillion anti-virus vendors and has produced one of the best anti-virus programs I've ever seen... they give it away for free... they respond QUICKLY to new viruses and by having access to all system internals, produce applications that can remove even the nastiest viruses from the system.
4) Microsoft now listens to their anti-virus group and makes changes to the OS to make it more secure from user blunder. Things like the ever annoying "Are you sure you want to run this app?" and also, in Windows 8, trying to deter the user from installing applications that are in their central online as harmful or incompatible.
Apple iOS is pretty damn secure because it's a bit harder for the vendor of a malicious app to get an app into the app store. If someone chose to add a virus/trojan/etc... to the app store, it's taken down very quickly if it's detected as such (unless we're talking about apple approved trojans) and the amount of information that has to be gathered on an app developer before they can publish an app makes it much harder to put things there without there being some recourse. Unlike the rest of the Apple Stores, it's not possible to purchase through PayPal. A developer has to use some identifying form of payment. Prepaid credit cards do however work... so if you get one of those and forge some info on it... you're good. Still... quite a big obstacle.
Mac OS X is still a rats nest of security hell as almost no one installs anti-virus software on it. The Anti-virus companies don't even take it seriously since the market for Mac sucks... most Mac anti-virus software really only checks to make sure you're not transmitting known Windows viruses through e-mail. People still trust it too much and the market for Mac is still probably heavily dominated by people who want to use FaceBook but can't find the 'Any Key'. They bought the Mac because the guy at the store said "You want a Mac because you don't ever have to worry about viruses" and they trusted the guy who was obviously a highly educated computer expert working for $10 an hour at a company who treats their employees like slaves and makes them wear a stupid blue shirt.
BlackBerry... haha I won't even begin to bash how useless their device security is. What'
Re: (Score:3)
1) People DON'T trust Windows apps like the used to... they're skeptical about viruses."
Windows is EXTREMELY secure because of its history of MASSIVE insecurity and the tens of thousands of viruses?
Microsoft logic at its finest.
Re: (Score:2)
Tell which does:
A) Software code quality and software design .... matter when it comes to bad security?
B) Software popularity among people
As you are saying that security is great if there are few users.
So if a few banks use software A, it is safe because it is just few users.
But if millions of users use software A, it is unsafe because it is lots of users....
You are saying that code quality and software design does not matter at all.
You are not talking about risks what crackers need to think as well.
Example
Devil's Advocate (Score:1)
Sandboxen should be as limited as chroot (Score:2)
If the sandbox isn't contained like a chroot environment it is a security issue and needs to be fixed. This reminds me of when web hosting services gave ftp access to users yet placed user content in /home directories. ie. Everyone's content was accessible by anyone with an account. Using user/group restrictions is a long way from sandboxing, IMHO. Linux is perfectly capable of creating chroot environments for daemons.