Re: Peeling off desktop Administrator Rights

["Flynn, Gerald" <flynngn () JMU EDU>]

I believe you'll find entries in the event log showing the file path
that was blocked. Using that information, you might be able to fine
tune the policy. Hopefully it won't require allowing executable
content in the temporary internet folders :)

I'm having problems with login scripts located on the domain controller 
and a local All Users script that we use to warn about use of an 
account with administrator privileges being blocked by SRP that I 
haven't managed to track down yet. The event log tells me the path but 
even when I permit that path in the policy, it is still blocked. In
these cases, I also get a popup window telling me the script was
blocked.

> -----Original Message-----
> From: The EDUCAUSE Security Constituent Group Listserv
> [mailto:SECURITY () LISTSERV EDUCAUSE EDU] On Behalf Of Kreider, Randall G
> Sent: Thursday, December 10, 2009 2:40 PM
> To: SECURITY () LISTSERV EDUCAUSE EDU
> Subject: Re: [SECURITY] Peeling off desktop Administrator Rights
>
> 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