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

[invalid at pizzashack.org (Derek Martin)]

On Fri, Sep 07, 2012 at 07:52:28PM -0400, Rich Pieri wrote:
> I have an even better example: Active Directory with roaming profiles.
> Active Directory is MIT Kerberos + LDAP + DNS, the same authentication
> system used by Athena. 

Horse be damned, I think you're still missing the point.  It's what
you're protecting, how accessible and available it is, and it's value,
that matters... not so much what solutions you're using to protect it
(unless they're just plain inappropriate for the job).  

To put it more plainly:  It doesn't matter if another user can access
my NFS directories, if all I have there are some photos from my
vacation in Honolulu, and copies of data they already have access to.
For that attack to be interesting, there needs to be something there
that the user shouldn't have access to, which has sufficient value for
them to try to get at it, AND real cost/consequences if they succeed;
and there needs to be no easy way to thwart the attack you described.
In most environments, you typically don't have the former, because all
your coworkers will likely have access to the same bits; and I already
explained a couple of ways how to do the latter.  Make sure their
directories have suitable permissions (well within your power), make
them use vlock when they leave their workstations (or disable all but
one VC), and be done with it.  Logging out is needlessly obtrusive and
costly in comparison, and no more effective.

So again, unless you're working on datasets that are highly sensitive,
which most of us are not, this concern simply isn't.  Your policy of
logging out doesn't help here, because there's nothing requiring help.
If you want to see the code I'm working on, just check it out
yourself.  If you want copies of my vacation photos, just ask...  I'll
send them along.  =8^)

And if you ARE working on sensitive datasets, you'd better take your
physical security more seriously, cuz if you don't you've already
failed.  And you'd better get yourself some better segregation of
resources, to make sure that those who shouldn't have access can't
walk up unchallenged to the workstation of a coworker who does and get
it.  If you can't afford to make that happen, chances are the data
you're trying to protect isn't as valuable as you think it is.  If
you're worried about the cleaning people, you have a different
problem, requiring a very different solution.  

If you're doing it right, this "log out when you walk away" business
is nothing but annoying small potatoes.  It's like the TSA: giving the
appearance of security by being annoying and obtrusive.  

> If you think that the horse has been flogged to mush then I'll leave
> you with this rhetorical question: would you trust a Windows login
> session to the screen lock?

I'll answer anyway:  I do not trust Windows for anything more serious
than playing games, period.  And actually I don't really even trust it
for that.  But I use it anyway for certain things, because the cost of
alternatives (like playing games on other platforms for which no
supported port exists) is too high (mostly in terms of the work I need
to put in to get/keep it working), or because there are no viable
alternatives.  The same basic principle applies:  Avoid evil unless it
can not be avoided; in that case choose the least evil (the solution
with the lowest cost, or no solution if the cost is higher than the
risk).

That said, if the overall site security is up to the task, then yes, I
would trust a windows session to a screen lock.  Because no one who
shouldn't have physical access will, and if someone does get
unauthorized access to something suitably sensitive, you'll have
sufficient monitoring in place to catch them and do something about it.  
And all without bothering your users unduly or significantly impacting
their productivity.

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