I've been asked to provide a program/script/whatever that enables or disables the
CD/DVD drive
USB ports
Floppy (!) drive
devices without requiring admin rights, that is, that can be run by a 'normal' user.
Ideally, something like a command line utility:
C:> foobar cdrom /disable
Any pointers, hints or clues gratefully accepted!
Thanks,
Rony
Without finding a security hole in Vista, it just plain can't be done. They require admin rights for a reason --- that's the type of things only admins should be doing.
There is a command-line utility (devcon.exe, available here), which will enable/disable devices, but it's still going to require admin rights. It's syntax is:
DEVCON disable {device id} where {device id} is one of the "Hardware ids" listed under the "details" tab of the device's Device Manager property page.
You could write a service that runs as a privileged account (e.g. Local System), and write a GUI front-end application which communicates with the server. The non-admin user can then run the front-end.
If you happen to be on a domain, I think you can disable all of that through a group policy.
First of all you should check if user without admin rights can do it from windows ui, using Device Manager. And I really doubt it.
Related
I am trying to write an Internet Connection Sharing app using the Windows INetSharingManager API. However, I must right-click and Run as Administrator for INetSharingManager::get_EnumEveryConnection to return any connections. Unless I run my app with admin rights, the network sharing is not that useful, because while I can share a wireless network, it will have no connection to the Internet. Furthermore, using Run as Administrator (or the manifest code to force this when launching my app) at all is not an option for me; I must do this without needing to elevate my app. (The reason for this is because I am targeting the Windows Store through "Project Centennial", and Centennial does not allow apps to elevate as far as I know.) Does anyone know a way I enumerate the network sharing connections without needing UAC admin rights?
UAC can't be disabled programmatically (There are some hacks but i recommend not using them). The best solution is, on detecting UAC, direct users the way they can disable UAC Settings.
Changing UAC settings programmatically on the users machine is not recommended.
In our software, user can select to make the application "Auto Run" during system startup. However, the user may not have admin rights. In this case, he won't have the rights to update the registry. I've tried both of the following paths w/o admin rights, and access is denied.
HKEY_LOCAL_MACHINE\\Software\\Microsoft\\Windows\\CurrentVersion\\Run
HKEY_CURRENT_USER\\Software\\Microsoft\\Windows\\CurrentVersion\\Run
So is there any way that I can "Auto Run" a program w/o having the admin rights, regardless of the platform(Win7, Vista, XP, etc)? Thanks!
You shouldn't require admin rights to write to HKCU\Software\Microsoft\Windows\CurrentVersion - the ACLs allow the current user to read and write to that key.
The most plausible explanation for this is that your anti-virus software is blocking your attempts to write to this key. Yes it's possible that somebody has applied an ACL to that key to deny you write access but it's pretty unlikely. On the other hand it's very common for anti-virus software to take exception to programs that modify that particular key.
To get Windows users to log on as regular users instead of admin, I need to check that all their applications run OK with limited rights.
Is there an application specifically aimed at checking that an application can run with limited rights, or is SysInternals' Process Monitor what everyone uses for this purpose?
Thank you.
Create a test account that has the permissions as the domain users of your application Login in as this user on a non-development computer. Preferrably a computer with a new operating system installation and all of the other "standard" company software. Install the software and run. This is the only way to really test your application.
Make sure you exercise the entire application.
Make sure install and uninstall work as expected and do not leave any artifacts behind.
Having the ability to restore the operating-system and software on the test computer to its original state is a great help.
Use the Permission Calculator Tool to make sure you handle obvious issues before performing this test.
I'm not sure if it would help since I never used it but I know there's a Permission Calculator Tool (Permcalc.exe) at http://msdn.microsoft.com/en-us/library/ms165077%28VS.80%29.aspx.
Permission Calculator Tool
(Permcalc.exe)
The Minimum Grant Set Determination
tool (Permcalc.exe) is used to
estimate the permissions callers must
be granted to access the public entry
points of an assembly. This tool is
new in the .NET Framework version 2.0.
It is intended for use by advanced
users.
Run this application on Windows 7/Vista with access control enabled. You may consider Windows 7 as such testing application :)
It is recommended to use non-administrator account with activated access control on a developer computer, when you write and debug the program. This creates some problems, and Windows developers hate this, turning off access control or using administrator account. However, working on Linux/Unix, we don't have administrator rights, and this is OK.
We have an application that programmatically maps network drives. On Vista with UAC on, we get some strange issues.
Our application maps the drive non-elevated, so if the user browses explorer and double clicks to run an exe, it prompts for UAC. So when they approve it, it prompts for a username/password for the share... Strange since the credentials are saved.
It turns out, an elevated process cannot access a mapped drive that was mapped from a non-elevated process.
To see this issue in action, do the following steps:
Run cmd.exe with no UAC
Run "net use w: \yourHostname\yourShare /user:yourUser yourPassword /persistent:yes"
Run cmd.exe as Administrator
Type "w:", and see the error message
At this point you can run plain "net use" and see the connection on the elevated cmd is Unavailable but the other non-elevated cmd sees it as OK.
Does anyone know a workaround to fix this issue? or maybe a way to map a network drive to "All Users"?
This is by design.
Even though the user account is the same, with the elevated version having a token with membership in the administrator group and addition privileges, the tokens are created independently and thus have different LUID's and appear to the kernel to be from different user logons. Since they are from different logons, mapped drives are not shared between them.
http://blogs.msdn.com/cjacks/archive/2007/02/19/mapped-network-drives-with-uac-on-windows-vista.aspx discusses this in additional detail.
Check out this link: Regedit Link
They describe a registry key that allows elevated users to access mapped drives and vice versa. This solves all my issues and was exactly what I was looking for.
EDIT:
The original link is dead, but here's the text as copied from the Jan 24, 2009 snapshot at www.archive.org:
If you are finding that you don't have access to mapped drives from your admin token try the following. When running as a protected admin you have two tokens and this key will maintain the connection for both tokes (that is my understanding anyway). It can also help to clear up issues with Login scripts.
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System
EnableLinkedConnections =(dword)1
Also of use is the "'Group Policy Scripts can fail due to User Account Control" section of this doc.
http://technet2.microsoft.com/WindowsVista/en/library/5ae8da2a-878e-48db-a3c1-4be6ac7cf7631033.mspx?mfr=true
I will be posting more information on this soon.
I have an app that normal users need to be able to run, but requires administrator privileges to actually function.
I tried to make the shortcut that my users run it with "Run as administrator" but this just causes a UAC prompt whenever they try to run the app.
Is there any way to elevate privileges programatically, without my users needing to go through a UAC prompt and/or knowing an administrator password? From a security standpoint, I understand that most applications shouldn't be allowed to do this, so I'm hoping there is some way to do it if I can provide a valid username/password pair, or something.
The app is written in C#, so a fully managed solution would be preferred, but p/Invoke Black Magic (or even writing an MC++ Wrapper Which We Do Not Speak About) would be more acceptable than disabling UAC entirely.
Generally this problem solved by installing a Windows Service which runs as SYSTEM or an admin account. Then your application can request the privileged action from this service.
Obviously to not pose a security threat ensure that your service can't run arbitrary code or something which might leave the all users vulnerable to privilege escalation attacks.
Winpcap and most of the other sniffing applications use a similar design to give sniffing access to unprivileged users.
Actually, why don't you just create a Task Schedule which runs the app with elevated privileges? As long as you setup the Task under elevation, it will not prompts you for a UAC when it is auto-run during reboot or whatever your trigger is.
Just make sure you set level=requireElevation in your manifest file, and task scheduler will run your app with admin rights without prompting your user for admin rights, as this had already been established when you setup the task with admin privileges.
It's not possible. You cannot decide to suppress UAC prompt.
You have to ask yourself:
What would happen on Windows XP?
The user is a standard user on Windows XP, and the application "needs" to run as an administrator. Are you:
going to refuse to run?
going to crash on startup?
going to show the user access denied error messages?
If the user is simply not allowed to run the application as a standard user on Windows XP, then UAC is your friend: it tells the user that they have to be an administrator.
And it even offers to let them (temporarily) gain administrative privileges.
But you have to ask yourself:
What would happen on Windows Vista?
In order to elevate, the user will need someone from IT to walk from three buildings over, so they can type in their credentials "over the shoulder". Perhaps you can make the user's life easier. Let 99.9% of the application run, and split off that 0.01% to an "administrative" module.