Educause Security Discussion mailing list archives

Re: Peeling off desktop Administrator Rights


From: "Flynn, Gerald" <flynngn () JMU EDU>
Date: Mon, 7 Dec 2009 15:25:16 -0500

We use BeyondTrust Privilege manager and one of its features is
that you can designate a folder into which a regular user can
place an executable and when run from the folder, it runs
with administrative privileges. The trick is to keep people
from putting ecard.exe there. :)

It also lets administrators identify executables that can
be run from anywhere with administrative rights by an end
user. I don't recall all the ways the executables can be
identified, there were several, but one was by Md5 hash.

As for self promotion of privileges, we've talked about a
web based system where:

1) Domain groups called computername-administrators" exist
   and belong to the local administrator groups.

2) A web based system allows a user to authenticate and move
   their regular domain account into the computername-administrators
   group. A database of computernames and people would have to be
   maintained to determine if the person is authorized to elevate
   to admin privileges on a specific computer.

3) The system could have a timer associated with it that would revert
   the domain account back to regular privileges after a user
   selected 1, 2, 4, 8 hour delay.

Are biggest hangup right now is the user<>computer mapping to
determine who is authorized to be an admin on what computer.

A simpler solution if one is contemplating giving users a
local admin account for them to login to when needed is to
have a script called with RUNAS that does basically the same
thing...moves the regular domain account into the administrators
group and puts something in task scheduler to change it back
at some point in the future.

For software installations, as the support organization matures and
acclimates to the needs of the more secure environment, they'll be
able to rollout installation packages for more and more software
titles into whatever software deployment solution they use...e.g. SMS.
Once the package is created for one person, it will be available
to others. There will always be a balance between support
resources and the number of packages supported though. Maybe
a day of delay for a person desiring to use a package used
by very few other people is a realistic business process? Or
maybe technology, like the aforementioned BeyondTrust, will
be leveraged to increase efficiency in those cases.

As for user responsibility for what they load on their machine,
I agree in principle but wonder what you're going to do if they
get fooled into installing antivirus2010, ecard.exe, or the like.
What are the repercussions?

Personally, I no longer believe it realistic to train people
to adequately defend themselves to the point that it can replace 
desktop management including least privilege configurations. We can
give them general guidelines (e.g. minimize non-work use of work
computers, avoid links and downloads and password queries
from unsolicited messages and popups) but parsing the many
ways email headers and URLs can be obfuscated goes beyond
the practical. And the ever longer lists of "steps to be safe"
is bordering on the ridiculous. I saw a half dozen or more
"ten/eight/six steps for safe online shopping" lists and many
had unique recommendations. Adding to the technical complexity
and associated confusion is the increasing sophistication of
social engineering attacks and the pace of communications. Its
too easy to create legitimate electronic communications and
too hard to prove to disprove their legitimacy. 

What all the lists boil down to is that you can't really trust any
electronic communications. Summed up, I think it's time we admit we 
are living in a more hostile world than what is commonly accepted 
(much to the dismay of e-commerce and "access anything from 
anywhere" promoters). Living in such a world means it's necessary
to apply basic security principals (least privilege, defense
in depth) more consistently and broadly. Will it decrease 
efficiency and innovation? Sure, somewhat. But constant
compromises and infections should be a sign that something in
the current system is not working and do nothing to promote
efficiency and innovation and threaten our core infrastructure
and constituent data. The support organization must evolve into 
something that can deliver faster, more sophisticated, customized 
services in a security environment made necessary by constant crime.



-----Original Message-----
From: The EDUCAUSE Security Constituent Group Listserv
[mailto:SECURITY () LISTSERV EDUCAUSE EDU] On Behalf Of Gary Dobbins
Sent: Monday, December 07, 2009 12:05 PM
To: SECURITY () LISTSERV EDUCAUSE EDU
Subject: Re: [SECURITY] Peeling off desktop Administrator Rights

Randy, I like your hybrid suggestion.  Taking it a step further, what
if users had the ability to self-escalate when they "really need to"
such as for a software install, but would normally work in non-admin
mode?  Nothing as convenient as Vista's UAC popup - I'm talking about
"logout as self, login as admin, install or whatever, then logout and
back in as self."

Not super convenient - and it shouldn't be.  It should be possible for
them to take full control when truly needed and without the risk of
doing so in a too-cavalier manner.  Just having to click "ok" to the
UAC is still too close to the level of social engineering where the
Trojan Horses live at the moment.  By making them re-login to do an
install, it can be logged, and tends to force them to close browsers,
etc. that might be carrying the Trojan Horse.



-----Original Message-----
From: The EDUCAUSE Security Constituent Group Listserv
[mailto:SECURITY () LISTSERV EDUCAUSE EDU] On Behalf Of randy marchany
Sent: Monday, December 07, 2009 11:44 AM
To: SECURITY () LISTSERV EDUCAUSE EDU
Subject: Re: [SECURITY] Peeling off desktop Administrator Rights

I presume the primary reason for preventing local users from having
admin rights on their desktops is to keep them from installing
"evil"
software.

If this is so, then my question to the group is "how long does it
take
a desktop user to get a "legitimate" piece of software installed on
their desktop? In other words, I have to use software package "A"
to
do my job. How long does it take for "A" to be installed on my
desktop? My informal straw poll respondents noted the time range to
be
anywhere from 1 day to 2 weeks.This is completely shocking to me.
Now, if my boss is breathing down my neck to finish a project by
tomorrow & I need software "A" to finish the project, I can't wait
1-7
days. The business process will trump this security process and a)
I
go up the mgt chain to get an exception b) I bring in my personal
computer, load software "A" on it and get the job done.

So, I wonder why there has never been a survey with the question
"How
long does it take to install a software package on a user desktop
if
you restrict local admin rights?". This is the root cause of the
"never ending battle" that I keep hearing about. If you make the
user
responsible for whatever they load on their machine AND enforce
that,
then what is the danger of letting them do so? Well, people with no
local admin privs can still "infect" a machine by using their
browser
so once again, what do we accomplish by "preventing" them from
loading
software? Seems like nothing is accomplished, hence, the "never
ending" battle.

Call me silly, but I think there is an end to this battle but we
don't
want to put in the effort to accomplish this. That end involves a)
enforcing user responsibility for their actions b) give them basic
training (you want to be able to install stuff, you have to sit in
this training) c) speed up legit software install requests.

I keep hearing about this losing battle with the users so why not
think of something radically different?

Just a thought for the holidays....

Randy Marchany
VA Tech IT Security Office

Current thread: