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:
- Re: Peeling off desktop Administrator Rights, (continued)
- Re: Peeling off desktop Administrator Rights Plesco, Todd (Dec 07)
- Re: Peeling off desktop Administrator Rights Iovino, Gabriel G (Dec 07)
- Re: Peeling off desktop Administrator Rights Eric Case (Dec 07)
- Re: Peeling off desktop Administrator Rights David Escalante (Dec 07)
- 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 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)
(Thread continues...)
