Home
| Calendar
| Mail Lists
| List Archives
| Desktop SIG
| Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings Linux Cafe | Meeting Notes | Linux Links | Bling | About BLU |
On Fri, Sep 07, 2012 at 11:34:14AM -0400, Rich Pieri wrote: > To elaborate a bit, Project Athena doesn't use encrypted home > directories but it does use Kerberos and AFS to provide a degree of > security. Even so, there is a formal policy of 20 minutes away from a > workstation: > > > If you are using a workstation in one of the Athena clusters and > > intend to keep using it but must leave it briefly unattended, you > > must limit your absence to 20 minutes or less and signal your > > situation to other users by taking one of the following actions: Sure, colleges typically do this not so much for authentication or authorization reasons, but for resource availabilty reasons. You can't have a couple of dozen students locking out the entire student body from using the lab, and you can't have your lab assistants tied up every 15 minutes rebooting all the workstations... In a case like a University lab, where the resources are heavily oversubscribed, you probably need such policies. In a professional/office environment, there are almost always better solutions: laptops, personal workstations, remote access, etc.. > I manage a small AFS cell based on the Project Athena design. Each user > in my cell typically has his or her own workstation running Scientific > Linux. Most of these are in shared office/laboratory spaces where > anyone in a given group has physical access to other group members' > workstations. My office isn't sooo terribly different, though we do all have our own blocks of cubes. The point is, you have to identify what can be compromised in such an arrangement, what is the REAL cost of such a compromise, and how does that cost compare to the cost of lost productivity and other costs of your security solution? If the cost of the solution is greater than the cost of the compromise, you're doing it wrong. If the thing your securing really is sensitive, but your organization is cost averse, then maybe you need to find a different solution (e.g. better monitoring tools, different technology or configuration, etc.). In the case you described, I think a better solution than interfering with productivity by forcing logouts is to have a tool that monitors logins, and reports cases of users logged into multiple machines, as well as workstations with multiple users logged in. Certainly you should have a policy against both of those things, and it's not hard to write monitoring tools to detect such situations in real time, enough that you can go investigate what the user(s) in question are up to before they get very far. There probably are already things that do that. And you can also disable having multiple virtual consoles... though that may hinder your ability to support a machine with a logged in user whose session is mangling the OS in some way. IMO draconian security policies are ALWAYS evil; they reduce both productivity and morale, and both of those things can be difficult to measure effectively, but both will have a dramatic impact on your bottom line if they falter for too long. Whether or not you institute one (or more) such policy really needs to be decided by whether it is clearly and demonstrably the lesser evil than (all of) its viable alternatives. OK, I think the horse has been flogged into puree by now... -- Derek D. Martin http://www.pizzashack.org/ GPG Key ID: 0xDFBEAD02 -=-=-=-=- This message is posted from an invalid address. Replying to it will result in undeliverable mail due to spam prevention. Sorry for the inconvenience.
BLU is a member of BostonUserGroups | |
We also thank MIT for the use of their facilities. |