Scenario : REMOTE DESKTOP CONNECTION
I am using a Windows 8 pc to give access to certain applications in a small lab(15-20 computers). I want to restrict access to certain resources(Hard Drives,Windows Settings, Control Panel, regedit, run, gpedit etc...). Simultaneously I want to give access to 1 or 2 application/files only. Is this possible in any ways?
N.B : I have researched about the gpedit settings but it does allow access to files whether it be in a hidden drive.
You can try using regedit settings, Inside which you can easily alter the machine settings :
Allowing and Blocking access
Change hardrive access settings
Restrict Control Panel Settings, all similar administrative stuff.
But remember it will restrict local access to.
So I would suggest you to design a small tool which accesses the remote resources through Shared Folders, this would most probably fit in your case.
Thanks!!
Related
I am writing a java agent that needs to write a file to a share drive using UNC format (\\servername\directory\subdir\etc).
I am getting "access denied" returned by the agent. The same code will write to the D drive of the same machine using either the D:\ or the UNC format.
I believe that this is a security limitation of Notes and that this can't be done, but hope I am wrong. Does anyone know of a way around this???
Security policy prohibits using FTP, and mapping a drive letter.
I have tried Apache commons FileUtils with no success, as well as just trying to create a File object.
(Note: not tagging java because I need notes specific answers, and tagging XPages even though it is not because the smart people hang out there)
This depends on global or local policies for the windows account which runs the domino server. Normally this is local system. Local System does not have access to mapped drives. Either change the service account which runs domino or give the privileges to the local system account.
Recently we implemented a feature which dynamically generates a LESS file in our App_Themes folder. This is done on application start.
This requires us to give the #ApplicationPoolIdentity# write access to the App_Themes folder.
Our system administrator, however, does not want us to give the #ApplicationPoolIdentity# that write access. For security reasons.
Is it insecure to do that? What are the security risks?
If there were any remote code execution vulnerabilities in your application, or within ASP.NET or IIS itself, anyone compromising your system through your application or web server will likely get a command shell, and be logged in as e.g. DefaultAppPool on your server.
If there is write access to a folder, then the attacker could write to this folder themselves.
For example, they could host their own content on your site at example.com/App_Themes/index.html, or they could upload an exploit that allowed priveledge escalation to that of administrator. In the latter case they would probably need executable permissions too, unless they could in someway make the webserver execute it, for example by requesting the URL of the dropped exploit.
Of course, the vulnerability has to be there in the first place for this to happen. Preventing write access too can be viewed as "defence in depth", however if this is needed by your application then it may be an acceptable risk. An alternative is to find another way to implement your desired functionality.
Where can I create/modify/delete registry keys to share data between users in the Windows 7 registry? Both of the users are non administrators and it shouldn't require admin privileges.
The application I'm working on uses the registry to write a key from userA and then userB can read/modify/delete it. Neither user has admin privileges and it won't be possible to change this.
Is there an official MSDN guide to how to use the registry in Windows 7? Any links describing proper use of the registry would be useful.
You cannot access HKLM without elevation, so you simply cannot do what you described.
I suggest some of the following:
1. Choose other data storage, eg. database, file, etc. that all your users can access.
2. Create a windows service running as LocalSystem (that gives RW access to HKLM) and make your apps talk to the service via named pipes/COM/a socket.
The registry is for writing configuration settings, not for sharing data between users, you're really using it for the wrong purpose.
However, if you have to, the only place in the registry that would make sense even a little would be in the HKEY_LOCAL_MACHINE hive, in Software\yourapp, but I'm fairly sure that there is nowhere in there that's writeable by normal users by default.
If you are able to, you could create that key and then change the permissions for the users group so that they have full access.
This wiki article might help in seeing how the registry is best used.
On Windows 7, access to HKLM is only for apps running as admin. If you have no manifest on the app, it will virtualize, meaning write to a different per-user storage.
I think you should use a config file in a per-application location that is not per-user, like %PROGRAMDATA%, and have your setup/install (which probably does run as admin) write a single key that tells where this file is. The non admin users can then easily read and write the file while using the application.
The registry is not really the right way to do this. Can you give us some more details about what you're actually trying to do?
Are the users logged in at the same time? In this case, some kind of interprocess-communication (IPC) mechanism might work. For example: named pipes, shared memory, sockets, etc.
If not, will you have a process running at all times (i.e. a service)? This could be used as a sort of drop-box mechanism.
If you've got an installer, you could create a directory that's accessible to both users (put them in the same group, for simplicity's sake). Then you could drop message files in there.
In short: the registry is really designed for long-lived configuration settings. Short-lived communications really ought to be done some other way.
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.
I posted this question a while ago regarding where to store non-user specific application data on Linux.
As you can see, I intended to use "/Library/Application Support” on Mac and perhaps "/var/lib" or "/usr/share" on Linux.
On an existing application (currently Windows only) we use “\ProgramData” on Vista & Windows 7 and “\Documents and Settings\All Users“ on Windows XP (both obtained using System.getenv("ALLUSERSPROFILE"), which does not work on Mac or Linux).
The problem I am finding with the Mac & Linux locations (unlike the Windows ones) is that they are not accessible by non-root/admin users, which sort of defeats the purpose of using them.
What is the best practice is this case? We could simply store the application data in the user's home directory. I wouldn't actually be dead against this, as it seems reasonable for the application to appear completely 'new' when a new user tries using it. The main problem this gives us is that each user would have to enter the serial number in order to activate the application (the activation info is part of the 'application data' we need to store). This isn't really ideal.
That said, if there is no real alternative then I suppose it will have to do.
What do you mean by non-user specific application data?
Read-only resources needed by application, such as localization strings or button icons:
on Mac they are stored in application bundle itself, in Resources subfolder
on Linux, they can be stored near application binary, in /opt/<app>/etc for instance.
Read/write properties, such as serial number:
you can consider this information as user-specific application data, so it should go somewhere in $HOME directory
you can consider this information as computer-wide application data, in which case its setting should be perfomed during software installation process, i.e., with administrative privileges.
/Users/Shared/ is writable for everyone. That said, if you need to support computer-wide licenses, the best place for serial numbers, IMHO, is indeed /Library/Application Support. You would have to use Authorization Services once to ask for an admin password and save the serial number there. If a user fails to enter the admin password, save the serial number in ~/Library/Application Support instead.