I'm doing some research on limitations of developing with VS2012/Windows7 with no local admin rights.
I found this link re: VS2003 and lack of admin rights. However can not find any information regarding VS2012. Can someone please help me?
You do not need administrative rights to develop applications using Visual Studio on Windows. I do it all the time. Like any good Windows user, my primary account does not run with administrative privileges.
There are only a couple of cases that I can think of where you might need additional privileges.
First is if you're doing something like developing Windows services or shell extensions (rather than, say, desktop or Web applications). Then you'll need to have the ability to install, remove, start, and stop services; install shell extensions; relaunch Explorer; etc.. Or better yet, just do all of your testing inside of a virtual machine, on which you can grant full administrative privileges with little or no security concerns.
Second is if you need to debug a process that your user account does not have access to. In practice, this would mean attaching the debugger to a running process that is not your own. Normally you won't need to do this, as the only processes you'll be attaching a debugger to are the ones that you're writing, and you'll own those processes. But if you do need to debug the operating system or processes running in the context of another user, you will need some degree of administrative privileges. Fortunately, you can grant the debug privilege separately from the whole suite of administrative privileges. Somewhat less fortunately, this still gives away the farm—a skilled hacker with debug privileges effectively has the run of the system. One hopes you would be able to trust your programmers at least a little bit, though! The worst case is they trash their own machine and it has to be reloaded.
Related
There are many sources telling it is bad to run apps under root inside Docker container but they always refer to this link: https://blog.docker.com/2014/06/docker-container-breakout-proof-of-concept-exploit/ with issue fixed long ago because newer Docker versions whitelist kernel capabilities.
Therefore:
Were there any other Docker exploits that worked under container root user but didn't work under container non-root user?
Were there any linux kernel exploits that worked under container root user but didn't work under container non-root user?
So, this is skirting the question a little bit but I'm going to try my best to give you an informative and in-depth answer to help you understand the issues involved with running an application as root.
First off, this isn't a 100% definite no-go. You can run applications as root, and in some cases you may need to. But in software, we have something known as the Principle of Least Privilege, also known as the Principle of Least Authority in some areas. This is an important concept in computer security, promoting minimal privileges on computers, based on users' job necessities. Each system component or process should have the least authority necessary to perform its duties. This helps reduce the "attack surface" of the computer by eliminating unnecessary privileges that can result in network exploits and computer compromises. You can apply this principle to the computers you work on by ordinarily operating without administrative rights.
By unnecessarily running an application as root is giving the program permissions to do things that it does not need to do - such as perform system functions and to manage a variety of the operating system's configuration settings. If your application is a basic website filled with cooking recipes, it does not need access to the system configuration files.
Applications are meant to be run with non-administrative security (or as mere mortals) so you have to elevate their privileges to modify the underlying system. This is how the general security model has worked for years.
It also makes applications easier to deploy and adds a layer of scalability. In general, the fewer privileges an application requires the easier it is to deploy within a larger environment. Applications that install device drivers or require elevated security privileges typically have additional steps involved in their deployment. For example, on Windows a solution with no device drivers can be run directly with no installation, while device drivers must be installed separately using the Windows installer service in order to grant the driver elevated privileges.
I apologise if this does not answer your question, but I've done my best to explain why you should not run applications as root. I hope this helps!
To combat image misuse. Running applications as non-privileged user helps keeping system secure when image users misuse Docker - e.g. run with --privileged or mount system directories into container.
I am making a Linux application using Python3 and Qt5. When user will install this application, It will create some files in /usr/share folder. To create the files the application needs to have root access.
I plan on having the application show a prompt box to user and user will enter the root password to give root access to the application. But I don't know that how can I give root access to the application by using that password?
This is a world of pain. It's certainly possible to have an application that runs as a normal user carry out certain actions as a privileged user, but I always feel that the need to do this suggests that installation and maintenance hasn't been thought through properly.
To elevate privileges, and assuming the "sudo" isn't appropriate (it probably won't be in this case), you will either need to use an operating system tool that does the job (prompting for credentials and then running something), or implement a helper for your program that has suid attributes on its executable.
I expect all Linux systems have access to "su", but the standard su doesn't have a graphical interface, which is a drag for GUI programs. You can collect the user credentials in your application, and then pass them to su (which is fiddly), or you can use one of the various graphical su-type utilities such as gksu. Of course, that only works if those utilities are available on your platform.
If you go the route of providing your program with a suid part that handles the work that needs elevated privileges, you need to be inordinately careful about security -- how you collect the credentials, how you verify that intruders can't do things they shouldn't, etc.
Frankly, it's a can of worms. I would think that it's nearly always better to provide your application with an installation or maintenance module that has to be run as root. That way all the hard work gets done by the platform.
I am developing an application in Visual C++ 2010, and the application is targeted to Windows 7. There is a task of writing some values to registry that will happen only in some special cases. And since in Windows 7, it is needed to have administrator privileges for doing so. How could I program my application in a way, that when it is needed for doing such actions, it asks for administrator privileges and it would not ask for administrator privileges at start time.
Thanks.
Like Mark said, you cannot elevate your privilege on demand. A quick solution would be to write a separate executable that does the writing part and launch it using specific commandline parameters when you need. Of course this executable would have to have the 'requireAdministrator' privilege in its manifest.
You can also design this program as a service and setup an IPC mechanism, say using a named pipe. The pipe itself could be created with a security descriptor that allows normal user access to it ensuring that the program running at lower privilege will be able to write to it.
The purpose of the second approach is to eliminate the nasty UAC prompt that would appear with the first solution.
I was recently working with a product from Symantech called Norton EndPoint protection. It consists of a server console application and a deployment application and I would like to incorporate their deployment method into a future version of one of my products.
The deployment application allows you to select computer workstations running Win2K, WinXP, or Win7. The selection of workstations is provided from either AD (Active Directory) or NT Domain (WINs/DNS NetBIOS lookup). From the list, one can click and choose which workstations to deploy the end point software which is Symantech's virus & spyware protection suite.
Then, after selecting which workstations should receive the package, the software copies the setup.exe program to each workstation (presumable over the administrative share \pcname\c$) and then commands the workstation to execute setup.exe resulting in the workstation installing the software.
I really like how their product works but not sure what they are doing to accomplish all the steps. I've not done any deep investigations into this such as sniffing the network, etc... and wanted to check here to see if anyone is familiar with what I'm talking about and if you know how it's accomplished or have ideas how it could be accomplished.
My thinking is that they are using the admin share to copy the software to the selected workstations and then issuing an RPC call to command the workstation to do the install.
What's interesting is that the workstations do this without any of the logged in users knowing what's going on until the very end where a reboot is necessary. At which point, the user gets a pop-up asking to reboot now or later, etc... My hunch is that the setup.exe program is popping this message.
To the point: I'm looking to find out the mechanism by which one Windows based machine can tell another to do some action or run some program.
My programming language is C/C++
Any thoughts/suggestions appreciated.
I was also looking into this, since I too want to remote deploy software. I chose to packet sniff pstools since it has proven itself quite reliable in such remote admin tasks.
I must admit I was definitely over-thinking this challenge. You have probably done your packet sniff by now and discovered the same things I have. I hope by leaving this post behind we can assist other developers.
This is how pstools accomplishes execution of arbitrary code:
It copies a system service executable to \\server\admin$ (you either have to already have local admin on the remote machine, or supply credentials). Once the file is copied, it uses the Service Control Manager API to make the copied file a system service and start it.
Obviously, this system service can now do whatever it wants, including binding to an RPC named pipe. In our case, the system service would install an msi. To get confirmation of successful installation you could either remote poll a registry key, or an rpc function. Either way, you should remove the system service when you are done and delete the file (psexec does not do this, I guess they don't want it to be used surreptitiously, and in that case leaving the service behind would at least give an admin a fighting chance of realizing someone had compromised their box.) This method does not require any preconfiguration of the remote machine, simply that you have admin creds and that file sharing and rpc are open in the firewall.
I've seen demos in C# using WMI, but I don't like those solutions. File sharing and RPC are most likely to be open in firewalls. If they aren't, file sharing and remote MMC management of the remote server wouldn't work. WMI can be blocked and still leave these functional.
I've worked with a lot of software that does remote installations, and a lot of them are not as reliable as pstools. My guess is that this is because those developers are using other methods that are not as likely to be open at the firewall level.
The simple solution is often the most elusive. As always, my hat is off to the SysInternals folks. They are true hackers in the positive, old school meaning of the word!
This sort of functionality is also available with products LANDesk and Altiris. You need a daemonized listener on the client side that will listen for instructions/connections from the server. Once a connection is made any number of things can happen: you can transfer files, kick on installation scripts, etc. usually transparently to any users on that box.
I've used the Twisted Framework (http://twistedmatrix.com) to do this with a small handful of Linux machines. It's Python and Linux, not Windows, but the premise is the same: a listening client accepts instructions from a server and executes them. Very simple.
This functionality can also be accomplished with VB/Powershell scripts in a Windows-based domain.
Usually we define iis web sites which allow anonymous authentication to run under the IUSR_ComputerName account which has very limited privileges. For example we may decide it cannot access the file system. How does that make our web site any more secured? The user cannot run code on it anyway - only our website code runs and we make sure it does not cause any harm.
Edit: I understand why it is good to be on the safe side (e.g. iis exploit). My question is if there is any direct reason. For example, if I would never give a guest account full privileges on a sql server as it would immediately allow him full control over my server. This does not seem to be the case with iis.
we make sure it does not cause any
harm
You can be never sure about it doesn't cause any harm. One day, it might be exploited, and probably the less privileged user would save your data. No offense, but no one writes perfect code, therefore no code is vulnerability free.
If you have any network service you should assume that some random person on the internet has a command prompt on your machine running as that services's owner.
Now ask what damage that user good do?
Typically, you may need to run your web site in a way that is a little less hardened from a security standpoint than, say, a domain server or exchange. For example, you may need to permit FTP access. Obviously, Internet web sites need to be accessed from the Internet so you cannot simply block all access with your firewall.
Because of the higher vulnerability, it is prudent to run your service with an account that has limited permissions. In the case where a malicious user does succeed in copying their own programs to be run on your server, those programs will have severe limitations as to what they can do.
You can run code on the server, for example you can delete files in a directory if the permissions are not set.