| |||||||||||||
Security quotes of the weekSecurity quotes of the weekPosted Jun 1, 2012 14:25 UTC (Fri) by copsewood (subscriber, #199)Parent article: Security quotes of the week
shell == root
That's only really true for shell users who are both knowledgeable and determined to break security. Multiuser security still usefully secures Alice's data against Bob's mistakes if they have the degree of mutual trust needed to share use of a system. Alice and Bob should not maintain data on the same multiuser system otherwise. I thought the other use cases were got rid of some time ago.
(Log in to post comments)
Security quotes of the week Posted Jun 1, 2012 17:17 UTC (Fri) by hummassa (subscriber, #307) [Link]
All that goes out the window in the moment Alice or Bob access the WWW.
All it takes, then is ONE malicious webpage that grabs a shell... escale the privileges... and has full control.
Security quotes of the week Posted Jun 2, 2012 9:56 UTC (Sat) by copsewood (subscriber, #199) [Link]
The use case I had in mind was more about sharing use of expensive servers than client/desktops. If malicious code can hijack a web browser and break its sandbox in order to grab a shell on either a single or multiuser system then you've got much bigger concerns than whether more than one mutually trusting parties share machine use. Another security layer is needed if this risk needs mitigation for you or other users, e.g. running different instances of the browser within separate VMs or using suitable MAC policy enforcement tools on the browser software. One extra sandboxing layer instance probably wouldn't be enough, given that CSRF and XSS threats between sites regularly visited are going to be a greater risk in practice than a malicious website code getting shell on the client machine. As a minimum I'd recommend all financial browser use should be in a separate VM per user.
The issue here is far more to do with whether the browser is secure and needs fixing or containerising regardless of whether on a single or multiuser machine, than whether Alice and Bob can trust each other not to use such a browser when they have different accounts on the same shared machine on which typically either Alice or Bob but not both installs this software.
Cost effective risk management != absolute security
Security quotes of the week Posted Jun 2, 2012 10:47 UTC (Sat) by hummassa (subscriber, #307) [Link]
1. practically all browser use is "financial browser use"; we're both subscribers to LWN!
2. Cost effective risk management != absolute security => yes, but depending on your definition of "cost effective" you could as well have written "Santa Claus != Easter Bunny".
Today, when we have expensive and shared server in an enterprise, the sysadmin normally will NOT allow anyone to have a shell account on that server. This way, we take out the "alice logged on the server, used mozilla/chrome and all went to hell" scenario. Good sysadmins will run only the minimum possible set of packages necessary to the day-by-day administration on an expensive and shared server exactly because of that.
In your example: suppose Alice and Bob the DBAs for MassaCorp and they have shell accounts in the database server. Jack is the database server sysadmin and Hugo is the network manager.
One MUST ask:
1. do they NEED to have shell accounts?
2. doesn't the DBMS has some way of they doing their jobs without shell accounts?
3. why would anyone but Jack -- and maybe Hugo, on demand -- have to have a human shell account on the database server?
My point is exactly that you don't need a shell account to install a rootkit, but if you have a shell account, installing a rootkit (not necessarily on purpose -- sometimes all it takes is trying to listen to a music CD, remember?) is trivial. And once you scaled the privilege, all protection went away anyway. That happens in any OS.
Security quotes of the week Posted Jun 2, 2012 11:14 UTC (Sat) by hummassa (subscriber, #307) [Link]
> That's only really true for shell users who are both knowledgeable and determined to break security.
1. For users that are not determined to break security, a simple post-it "please do not access the files under /home/me/pr0n" suffices (this is an exaggeration, if it's not totally clear...).
2. As I mentioned in my other comments below, mistakes made by unknowledgeable shell users can eventually lead to total box compromise.
|
|||||||||||||