|
|
Subscribe / Log in / New account

Security quotes of the week

Security quotes of the week

Posted Jun 2, 2012 9:56 UTC (Sat) by copsewood (subscriber, #199)
In reply to: Security quotes of the week by hummassa
Parent article: Security quotes of the week

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


to post comments

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.


Copyright © 2025, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds