Boston Linux & Unix (BLU) Home | Calendar | Mail Lists | List Archives | Desktop SIG | Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings
Linux Cafe | Meeting Notes | Blog | Linux Links | Bling | About BLU

BLU Discuss list archive


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Discuss] can one safely login multiple times to the same user on a modern Linux desktop?



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
BLU is a member of BostonUserGroups
We also thank MIT for the use of their facilities.

Valid HTML 4.01! Valid CSS!



Boston Linux & Unix / webmaster@blu.org