Educause Security Discussion mailing list archives
Re: Peeling off desktop Administrator Rights
From: "Flynn, Gerald" <flynngn () JMU EDU>
Date: Mon, 7 Dec 2009 18:44:26 -0500
-----Original Message----- From: The EDUCAUSE Security Constituent Group Listserv [mailto:SECURITY () LISTSERV EDUCAUSE EDU] On Behalf Of randy marchany Sent: Monday, December 07, 2009 5:43 PM To: SECURITY () LISTSERV EDUCAUSE EDU Subject: Re: [SECURITY] Peeling off desktop Administrator Rights 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?
Whatever it takes for point, click, and install in any of the following cases: - if it's an SMS advertised package - if it's a BeyondTrust enabled package - if it's an install in the BeyondTrust folder - if the user knows their admin account password they can either RUNAS, logout/login as their admin account, or elevate their regular domain account by placing it in the administrator's group. This is the least desirable option and we are working on the other options to make it less necessary A little longer if they need help and the HelpDesk or College/Departmental technology coordinators need to get involved. But this is less of a technical limitation than a teaching or resource limitation.
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.
I'd disagree. I say we're trying to alter the environment to be more resilient in the face of constantly defective products, compromised legitimate web sites and services, interconnected systems open to abuse, and sophisticated criminal attacks while our end user devices are used to access more and more sensitive and constituent data.
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".
A least privilege account can limit the damage exploit payload can do. If the payload assumes administrator privileges, running in a least privilege account may keep it from doing anything. Also, many infections are still due to the same old operator installed malware problem, not drive-by attacks. Not so much from cute programs as from well engineered attacks scaring or otherwise motivating operators into installing fake anti-virus software, fake video codecs, and/or fake updates.
So, are we going to ban www surfing? Doesn't that impact the business process?
Depends where I'm surfing and what my job function is. :)
Imagine if we sysadmins aren't allowed to surf sites like sourceforge, packetstormsecurity, etc. If that happens, then our job becomes much more difficult. 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? That's why I'm curious to see how long it takes from the time a user requests a software package to be installed on their desktop to the time it actually gets installed. I think you'll see what I'm talking about when we look at the responses. -r.
Current thread:
- Re: Peeling off desktop Administrator Rights, (continued)
- Re: Peeling off desktop Administrator Rights Eric Case (Dec 07)
- Re: Peeling off desktop Administrator Rights Eric Case (Dec 07)
- Re: Peeling off desktop Administrator Rights Stanclift, Michael (Dec 07)
- Re: Peeling off desktop Administrator Rights randy marchany (Dec 07)
- Re: Peeling off desktop Administrator Rights Eric Case (Dec 07)
- Re: Peeling off desktop Administrator Rights Flynn, Gerald (Dec 07)
- Re: Peeling off desktop Administrator Rights Flynn, Gerald (Dec 07)
- Re: Peeling off desktop Administrator Rights Flynn, Gerald (Dec 07)
- Re: Peeling off desktop Administrator Rights Eric Case (Dec 07)
- Re: Peeling off desktop Administrator Rights randy marchany (Dec 07)
- Re: Peeling off desktop Administrator Rights Flynn, Gerald (Dec 07)
- Re: Peeling off desktop Administrator Rights Eric Case (Dec 07)
- Re: Peeling off desktop Administrator Rights randy marchany (Dec 07)
- Re: Peeling off desktop Administrator Rights Stanclift, Michael (Dec 08)
- Re: Peeling off desktop Administrator Rights Stanclift, Michael (Dec 08)
- Re: Peeling off desktop Administrator Rights Valdis Kletnieks (Dec 08)
- Re: Peeling off desktop Administrator Rights John Hoffoss (Dec 08)
- Re: Peeling off desktop Administrator Rights Kreider, Randall G (Dec 10)
- Re: Peeling off desktop Administrator Rights Flynn, Gerald (Dec 10)