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

[invalid at pizzashack.org (Derek Martin)]

On Wed, Sep 05, 2012 at 11:32:36PM -0400, Rich Pieri wrote:
> On Wed, 5 Sep 2012 20:19:03 -0500
> Derek Martin <invalid at pizzashack.org> wrote:
> 
> > Even if this isn't your situation, the fact is your session contains a
> > lot of state, and having to recover that state even every morning is
> > counterproductive.
> 
> Everything I do more than twice by hand in short order gets automated
> because I don't have time to waste reconfiguring the session every.
> single. day.

Very little of what I do other than window placement has automatically
repeatable state.  So this basically isn't interesting.  It would
typically take anywhere from a half an hour to half a day to reproduce
all the state I have laying around.

> > [*] Where "likely" means that the risk of such an intrusion is
> > significant enough that the cost of failure justifies the cost of
> > protection.  The loss of productivity this kind of nonsense causes
> > adds up fast, almost certainly measuring in the millions of dollars
> > annually.
> 
> As I just noted, the kind of environment under discussion is more or
> less open clusters of workstations where anyone can sit down and use any
> node. Physical security is effectively nonexistent so you need to rely
> on logical security, things like strong encryption on authentication
> (like Kerberos), maybe N-factor authentication, encrypted home
> directories (like EncFS or ecryptfs), and so forth. Remote access (like
> ssh) is disabled.

MAYBE you need to rely on that... maybe you don't.  This is not
remotely like the environment I live in (though it would be possible
for me to sit down at another engineer's workstation, with my various
encryption keys on portable media, and work on their machine).  Nor, I
expect, is it particularly typical.  We do use Kerberized NFS but I
don't use NFS for anything that matters anyway, and most engineers
don't use it for storing things they're working on.  Having hundreds
of engineers run compiles over NFS would be an inane waste of
resources.

There's nothing I'm working on that any other engineer in my company
couldn't get at via source control system, which roughly = NFS only
without kerberos or encryption (it's cryptographically protected until
the files hit my disk).  And there's nothing on my workstation that I
would consider personally sensitive data.  So your threat model is
bogus.  The only real threat is if some non-employee managed to gain
physical access to my machine and walk off with it, and your
overzealous measures don't help with that at all.  

> So, you sit down in the morning, log in, get all your software tokens
> set up. Everything good. And you run up an xlock and go lunch. Me, I
> see you've done this, sit down, switch to a text console and log in
> myself. 

This hardly matters because remote access via ssh is enabled, on top
of the other issues I mentioned above.

And if it did matter, I would run vlock.  So good luck with that.

> I now have access to your unlocked home directory modulo whatever
> file permissions and ACLs you may have set. Since you've been sloppy
> with your session security I will assume for the sake of discussion
> that you've been similarly sloppy with your file permissions 

Good luck with that too... Wrong and silly assumption, and I dispute
that leaving oneself logged in with the screen locked is sloppy
security.  My home directory is 700, FWIW.  Things I want to share are
on my NFS home dir, which is less restrictive.

> whole directory is encrypted after all. I may not have write access
> to anything in your $HOME but I can copy all or most of it out and
> peruse it at my leisure.

No you can't.  But you can certainly take the disk out when I'm not
around, and do the same.  Or reboot the machine to single user mode
and copy it off to a USB whatever.  

> If you had logged out instead of locked the screen then your home
> directory would have been unmounted leaving only the encrypted version
> visible. There's your clear and present threat thwarted by simply
> logging out.

Clear and present?  Not in any computing environment I've ever managed
or worked in.  Most companies don't need this kind of security, and as
I said, the cost of this loss of productivity is in the millions per
annum for any given company of medium size, and substantial enough for
any company.

Let's say you have a small company, 50 engineers, average salary of
$75K, average productivity of 6 hrs / day = 30 hrs / week (assume 48
weeks with time off) per year.  Now you force them to log out every
day.  On average let's say it takes them .5 hrs to reproduce the state
of whatever they were working on yesterday, which in my estimation is
pretty conservative, counting logging in, paging into their brains
what they were doing yesterday with nothing to serve as a reference
point, getting apps set up, loading whatever files they were working
on, reviewing results of previous compiles / simulations / etc. etc.
etc..  The monetary loss of productivity is easily:

  .5 hrs * 5 days/week * 48 weeks * (75k / (6 * 5 *48)) * 50 engineers
 = $312,500 annual productivity loss 
 
assuming I didn't botch the math.  And that salary estimate is
probably also on the low side...  I'm one of the most junior people on
my team (at least in terms of job title and experience in my current
role), and I make substantially more than that.  

Now take a medium company with 10x as many engineers, and you're
talking over $3M a year of productivity loss, and I maintain that this
is most likely a very conservative estimate.  I expect it would be
closer to double or triple that amount, with the additional cost of a
higher error rate, due to loss of context.

If you don't truly NEED the additional security -- and let's be clear,
there are environments for which that IS true, but most of us don't
work in one of those -- logging out every day is stupid.

-- 
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.