I use Windows 10 Home with a separate Admin account, using a limited account for day to day work. I've installed Docker (community edition) using the admin account, but when I switch to the limited user, it wouldn't let me run it unless my limited account joins the "docker-users" group.
This question isn't to ask how to join that group (see this other question) but instead to to ask why the group is needed. Is this a security measure? Do I open up a vulnerability by using Docker from a limited account?
If it isn't a security measure, what reasons would I have for denying a user membership of this group?
Being able to create docker containers should be considered a privileged action because it allows someone to host new services on the underlying server, including hosting interfaces on low-numbered ports (22, 80, 443 etc).
The "docker-users" group exists to allow non-admin users to perform these privileged actions, bypassing the security control that required an admin user. This exists for the convenience of managing docker containers from a standard user rather than an admin user. The security benefit of this is that you can further lock down your admin account as you no longer need to constantly access it for docker management. The downside is that the compromise of any account in the "docker-users" group could result in a compromise of your whole docker environment.
In the case where you are the only one using your PC, then it doesn't have much impact because if someone were to compromise your account, you would have bigger issues anyway. In shared computer environments, you may have some select users with the privilege to use docker, but allowing all user would significantly increase your attack surface, and allowing no users would mean you have to provide each user that requires access to docker with a privileged account.
Related
I'm trying to create a Windows service that has the right to create additional services. But I'd prefer not to make this service run with an Administrative login.
The users rights are otherwise quite limited - I just need it to be able to spin-up a service on request.
I've seen mention online that SC_MANAGER_CREATE_SERVICE is a permission you can now assign and/or change, but I haven't seen much on how that is done. There is mention of being able to change permissions for individual services via subinacl, via OpenSCManager and the - gulp - sc command. But these examples show how to change the permissions on a single service, not how to give a user SC_MANAGER_CREATE_SERVICE permissions.
However, I've noticed that the documentation on CreateService specifically says that it requires administrator privilages - so perhaps it's simply not possible.
Am I going to have to start the service with an admin account? Or does anyone know another trick?
See Service Security and Access Rights:
To get or set the security descriptor for the SCM, use the QueryServiceObjectSecurity and SetServiceObjectSecurity functions with a handle to the SCManager object.
Be aware that having the right to create services gives you effective administrator access, since you can create a service to run as local system. So you do need to be careful not to grant that right to accounts that untrusted users have access to, to make sure that all accounts with that right have strong passwords, and so on.
This also means that if your system service is compromised by a remote code execution vulnerability you haven't gained anything, the attacker will still be able to get control of your system. If the service is at a high risk of direct attack, it may be wise to instead have a second service that is responsible only for the tasks that require special privilege. However, for a service that is unlikely to be directly attacked, or is considered reasonably secure, running without administrator privileges (other than the ability to create services) may prevent a less severe vulnerability from being exploitable, or limit the damage caused by a non-security-related bug.
See also Granting service control manager access permission to user outside of administrator group on Server Fault, the answer shows how to change the SCM permissions from the command line.
Try opening an handle to the service control manager with the WRITE_DAC access right, and change the security of it by calling SetServiceObjectSecurity to change the dacl of the service control manager. Don't forget to do the same thing for the service registry key (HKLM\SYSTEM\CurrentControlSet\Services) using RegOpenKeyEx and RegSetKeySecurity function.
WARNING
Be aware that this is a potential security risk since it would allow a standard user account to elevate its privileges to SYSTEM.
We have several developers, working on the same application (to be deployed on Heroku).
We know they can open separate Heroku accounts, and share the application using "heroku sharing:add".
But is it possible to use a single "team" account? Are there limitations on people logging in simultaneously from different PC's ? Or any other technical reason to avoid it?
Note we're not worried about them overriding each other's deployments, because it's for development (not production), and it's a small team.
Thanks :)
Although you can grant limited access to multiple Heroku accounts, only one "Owner" account has privileges to modify the account configuration.
If more than one person needs to modify your account/app configuration (ie: changing/provisioning add-ons, etc), it's best to create a shared e-mail/password stored in a secure password manager like 1Password. However, this is a hassle and opens up some vulnerability. It may also be against Heroku's TOS, but isn't likely enforced.
I would recommend using multiple accounts for anyone who needs read-only or deploy access. I would limit a shared Owner account to the privileged users who need full access.
I have developed a .NET Windows Service (in VS2010) that needs to:
Access shared folders (read/write) on machines on the local network
Write to HKLM/SOFTWARE part of the registry
Write files and create folders in all parts of the local file system (ex. in root of C:)
Download files from the web (using http)
My service must do well with all Windows (PC) operating systems, starting from Windows XP SP3 and onwards.
Problem: Which service account should I choose for my service?
Normally, I would use either “LocalService” or “NetworkService”, but none of those grants all needed privileges by themselves.
Should I use the “LocalSystem” account then? Or, should I create a complete separate account for my service's use only (this should then be done automatically during installation)?
For now I use the “NetworkService” account and just adds it to the adimistrators group during installation, which works fine. But I think this approach ruins the whole idea about limited service accounts and thus poses a security risk - don’t you agree?
You should not use LOCALSYSTEM. This has far too much power and all best practice tells you not to use it.
In my view you should be creating a local user with appropriate rights as part of your installation. This is a fairly common practice for server/database products.
Sounds like you need to separate out your requirements.
You mention needing access to shares on other computers, but then you also mention that the machines this service will be installed on won't necessarily be part of the domain.
Have the service execute under a user account that grants you the appropriate LOCAL permissions. Then have some type of alternative user account with access to the appropriate shares that your service knows about and impersonates when needed.
Now, with regard to writing and creating files in the ROOT, that's going to be interesting. Your service will need full administrative permissions in order to do this on a Windows 7 box if UAC is turned on. Which, it would probably be safe to assume is on machines you don't directly control. Either eliminate this requirement or you'll have to live with the idea that your service is a security risk.
I have a python application designed to run as a service on Linux, and I've been asked to install it on a Windows XP box in an office where there are no Linux machines (for me, this makes it a bizarre and confusing place as I have virtually no experience developing for Windows).
On Linux the application has its own user, and the application and database credential file reside in an encrypted folder accessible only by that user. (I'd like to state that I am not a cryptologist, and that if there are already glaring security errors in this set up I'm very happy to have them pointed out to me!)
How can I achieve an equivalent level of security by similar or different means on a Windows XP machine? That is to say, how can I prevent those who have access to the computer or the disk altering the program or reading the credentials?
A little background: the host windows box is a workstation used every day by users with non-administrative privileges. The secure assets are personal data roughly as sensitive as, for example, a school report. The application is intended to be used by about 10 people who authenticate to the application with individual passwords (stored salted and hashed in the database).
There is a very similar question that received the answer:
on Windows you would store the credentials in the registry in a location protected by an ACL
However, it doesn't touch on the aspect of protecting the program files, and further it seems to assume a higher level of Windows experience than I currently enjoy :) I have no idea how to protect registry items with an ACL, nor how I would then be able to access the protected keys from my program. Simple instructions for a developer in an unfamiliar environment would be greatly appreciated!
Your question is unclear about what your application does and what your security requirements are. I'm going to make some assumptions, and provide an answer based on them. If these assumptions are incorrect, please clarify in a comment and I'll update.
I'm assuming you have an application that:
stores sensitive data in a database stored in a DBMS installed on the workstation
is installed on a shared workstation
each user has their own login (non-admin)
allows different users to log on and interract with their data
user runs applicaiton which connects to a service
service connects with database, delivers data to users
service runs under its own user account
If this is correct, then you shouldn't have much issue.
The service can run under any account, but it would be easy enough to have it run under one of the standards (Local Machine or Network Service). Configure the database so that only this account can access it. In Sql Server, I'd only grant that user account (and admins on the box) login and access rights to the database.
This is the only security you need, if the users aren't admins. Now, when the frontend connects to the service, the user can provide the username/password and the service can authenticate against salted and hashed passwords stored in the database. All this is secure as long as 1) each user has their own login 2) communications are secure (using named pipes or SSL) and 3) no virii or keyloggers are running under an admin's credentials.
You can configure your service as to what account it runs under by running services.msc (or right-clicking on MyComputer and selecting Manage or clicking on Services under the Admin tools menu in Control Panel or probably in a number of different ways).
Bring up the list of services, right click on your app and hit Properties. From there, make it look like this:
Let me state first: I know that any user that wants to run a program (or even log in), has to have access to (probably at least) the Windows system directories and the shared libraries in %ProgramFiles%, but I'd like to be able to access Skype, for example, by running it with an unprivileged user and make sure that it can't access any unnecessary files.
I fear that the only way to do this would be to identify all of the gazillion directories where I store files that I don't want this user to access and then create a new user group that can access these directories, or run Skype and Azureus in a VM.
Is there a better way?
Normally, accounts are members of the Users group at least, which does have access to many things. You could make the account a member of no groups, or the Guests group which is very restrictive.
The real issue is that the program's token (an internal security object that keeps track of what security identities a running process has) will contain the Everyone and Authenticated Users groups, which also have read access to lots of stuff. There is no way to create an account without those groups. You could remove the access that Everyone and Authenticated Users groups have to most everything, but it would be a lot of work to track all those down.
I would say that creating a standard user or guest access account for untrusted programs would be plenty secure enough. To support self-updates and to keep related files in the same place, I suggest you install those programs directly in the profile of the user account they will be running as, e.g. C:\Documents and Settings\skype\Program Files\Skype
If you want to get really fancy, you can use a restricted token to either make the Everyone, Authenticated Users, etc. groups deny only (so they can't grant any access) or create a Restricted SID list. This will be difficult to implement because there are global objects that programs will expect to access that the Everyone group has access to, which is normally a safe choice.
See CreateRestrictedToken Function.
There is also an open-source command line program I created a program for creating restricted tokens and job objects on the fly for that purpose: UlimitNT
Maybe sudown is a solution. It's a sudo-similar (as known from Linux) approach to running as unprivileged user, but having the possibility to promote to an administrative account (with password) when needed.
I suppose you could lock down the machine so the user can solely log on, not even start skype with his rights, but start skype by "run as" with sudown.
Besides using a VM you could look into using a Sandbox. Look at Sandboxie fox an example.
simply use acl apis (samples in msdn)