Re: Peeling off desktop Administrator Rights

["Kreider, Randall G" <kreiderr () ETOWN EDU>]

Hello,

I light of recent posts we've been investigating our own usage of SRP, particularly as it relates to browsers.  We're 
seeing some issues regarding limiting to the basic user.  Our largest issue is that it breaks the ability for users to 
update the browser itself (FireFox) and Windows updates.  We handle some of the updates through other means such as 
WSUS and Group Policy, but how are you working around some of these things.  

Findings are below, and as you'll see there are caveats to each one.

Internet Explorer: SRP will restrict running of downloaded executable files from running within the browser (i.e. hit 
Run every time when presented with downloading a file). What also apparently breaks is the running of Active X 
controls, although this is hard to verify. In either case, downloading the .exe or .msi file (if one exists) to the 
computer and running it locally works OK. Running Windows Update from the local machine also does not work (although 
domain computers will get any approved updates installed automatically from WSUS).

Mozilla Firefox: SRP will restrict running of downloaded executable files from running within the browser (i.e. double 
click the file from within the Downloads window when downloading a file). As with IE, downloading the file to the local 
machine and running it from there works OK. What also breaks with Firefox is the ability to update the program from 
within the Help dialog and the program's ability to know that an update is available (it can only do this when running 
the program as an administrator).

Google Chrome: This is a funny one; Chrome installs and runs itself from a UserData location (from the directory of the 
user's profile stored on the machine) and thus doesn't need admin rights to install or run since the user who 
installs/runs it already has access to that directory location (whether they are an admin or not). To take admin rights 
away from the program is thus a bit of an exercise in futility as it isn't accessing system files to begin with. In 
this case downloading and running executables behave just as if you were downloading them locally to the computer and 
running them that way (so with our SRP exercise at that point the user would be an admin running the download locally). 
We may not be able to do anything more with this program but it also may not matter given how the program treats 
executables to begin with. I also have no idea how many campus users install and run Chrome at all.

Thoughts?

Randall Kreider
System/Network Administrator
Elizabethtown College

-----Original Message-----
From: The EDUCAUSE Security Constituent Group Listserv [mailto:SECURITY () LISTSERV EDUCAUSE EDU] On Behalf Of John 
Hoffoss
Sent: Tuesday, December 08, 2009 1:47 PM
To: SECURITY () LISTSERV EDUCAUSE EDU
Subject: Re: [SECURITY] Peeling off desktop Administrator Rights

> > > On Mon, Dec 7, 2009 at  4:42 PM, in message
<7d7b8eb40912071442t729e43afhc9b538b3037dbaf9 () mail gmail com>, randy marchany
<marchany () VT EDU> wrote: 
> It's been very interesting to see the different scenarios that you
> guys have for delegating some priv set to general users. But, IMHO,
> all of these don't address the real issue: how long does it take for a
> general user to get a software package installed on their desktop if
> you don't allow them to do it themselves? Hours? Days? Weeks?

But that's not the real issue! The real issue is non-technical staff and faculty having access to perform 
administrative functions on their system without the requisite experience and knowledge to execute caution. Say nothing 
of social engineering attacks like phishing that can very convincingly disguise illegitimate content. Also say nothing 
of the technical staff and faculty that do have that experience that still do silly things like browse the web from a 
server. 

Restricting that access provides a great amount of control and greatly enhances system security. 

> As a long time sysadmin (25+ years) I've beginning to think that we
> (sysadmins) are more of the problem than the users because we set up
> environments that make address OUR needs/likes and not so much the
> user requirements. That model dooms a site to failure, I think.  The
> "original" purpose of these restrictions was to prevent users from
> downloading malware/trojans  that were embedded in "cute" programs
> like aquarium backgrounds, etc. So, the sysadmin in me says "no, no,
> no, you can't do that" but we never built an efficient mechanism to
> allow a user to download what THEY need to do THEIR job.  I know one
> of the reasons why I went down this path was because there was only 1
> of me and 10K users. 2 events would overwhelm my response
> capabilities. The attack vectors have changed. Now, malware gets
> inserted on a desktop without any active user intervention other than
> surfing the www and having malware downloaded to their desktop which
> is the very thing we tried to prevent with our "no local admin
> rights". So, are we going to ban www surfing? Doesn't that impact the
> business process? Imagine if we sysadmins aren't allowed to surf sites
> like sourceforge, packetstormsecurity, etc. If that happens, then our
> job becomes much more difficult.

As another poster pointed out, there are still holes in browsers and other software, but it's *much* more difficult to 
exploit a system when a user is a user and not an administrator. But no one is saying you can't browse the web. (Unless 
you're on a server...) What you can't do is browse the web as an administrator. If the desktop is properly restricted, 
the user is not exposed to that kind of risk nearly as much. And when they are, AV and antimalware is significantly 
more effective.

But your point about allowing users the software they need to perform is valid, but that's not necessarily the 
sysadmin's challenge, it's usually the helpdesk's. When I did support while in school, I was able to service every 
request immediately using remote desktop support (ZENworks) so if a user said they needed something installed and it 
didn't appear to pose a threat or a licensing issue, it got installed. Of about 1,200 systems, I went from reimaging 
10-20 per week to 2-4. Sysadmins were happy, users were happy, I was happy.

>  I look at some depts here on campus who let their users install
> whatever software they want and I don't see any significant increase
> in bad events happening in those environments. This leads to me
> question how effective was the user ban?

But presumably that department requested an exception, and if your statement here became untrue, I'd bet you'd be going 
in with a crowbar to remove those privileges from normal users...

Work smarter, not harder, folks.

-jth