I was testing UrBackup Client on a Windows 10 PC with multiple user accounts (two domain accounts and two local, all four on the same PC).
I tried to install UrBackup client as regular user, and I had to provide administrator credentials, fair enough, but that didnt work either, got some errors, so I had to run the installation as “administrator” altogether.
The installation went OK and UrBackup client is working, the service is running with the System Account.
I just realized that all folders inside c:/users are being backed up (including profile folders for the other users in the same PC), and if the current user (a regular user, not admin) goes to the UrBackup Web (authenticating also with a regular set of credentials, enabling visibility only for his backups) then he can restore any file, even files inside the other user’s folders.
That regular user dont have the rights to see the “myd ocuments” folder for the other users (inside his own PC), how come he can now restore those files via UrBackup?
Am I doing something wrong?
How can I make this more secured?
Yes, correct. Users can restore directories/files they can read to their previous versions. They cannot get access to files they couldn’t read that way (if they couldn’t read the files previously).
On second thought this is really sub-optimal on a server when e.g. the web server user can restore the whole server. The problem is/was this is really hard to do correctly, I think. The first question is what it should do.
For example, on Windows there are folders which even an administrator cannot access and an administrator would expect them to be restored. What to do with files which the user could previously read/write but now cannot? (error out during restore?).
What do you think it should do in such a case?
I would vote for standard users only being able to restore their own files in their user directory, administrators can restore anything on that machine and if they attempt to restore something they do not have permission for then they receive an error stating as much.
Agree with John3354, the only problem I see is how UrBackup will determine which objects the current user has permissions to.
But he has the concept right I think, the standard users should be able to see/restore all files but the ones that are inside a profile that wont belong to them.
Another option would be allow the standard user to restore them, but never to a location other than the original location, so the permissions are taken care of.
You have to remember also that the standard user should be able to create full images and also restore them (including files that he/she is not allow to browser, otherwise the UrBackup functionality would be limited.
This happens only when the “with tray” version is installed. The “no Tray” version is not a issues as it is operated from the server end and you have the control to not allow standard users to do the restore.
With this said, theoretically Urbackup service should be able to check: 1) if a “with tray” version issued the restore command; 2)the login user’s privilege of the operation, and based on the result Access to other’s file should not be granted and return ACCESS_DENY or similar.
But I tested restoring the files to a different location, and a regular user could read the administrator files that were originally under the administrator’s profile, file which the regular user could not read before the backup was done. Perhaps I need to test it again.
Im not sure if it should even let you restore those file on a different location, because that could be an external HDD, that could be taken to another machine and force ownership on the files, without leaving trace. In any case, I will test the scenarios later this week. Thanks for the quick feedback.
I was testing yesterday, with a different FreeNAS box and a different Windows machine, same problem with security.
Let me try to explain this, but it is very basic:
The Client is a Windows Machine, that belongs to a Domain, on that Windows machine there are several profiles (belonging to people that at some point logged in on the domain using that machine):
User 1: The regular user that is local admin on the machine and standard user on the domain.
User 2: Another, same as User 1
User 3: The local administrator account
User 3 The Domain Admin
This is what happens:
“User 1” install the urbackup Client on the PC with default options and let it run.
The backup gets done few minutes later.
“User 1” goes to the urbackup web interface with his credentials, that let him see only the backups for his PC.
“User 1” navigates to the tab “backups”, pick a full file backup from his PC and navigates all the way to someone else’s profile, for example 'C > Users > “User 3” > ’ which in our example, is the local admin.
When on that path “User 1” can see folders and file that were originally inside that other user profile, and if “User 1” click on any item there (file or folder), the item can be downloaded locally on his PC, on any other folder.
After the item is there, then “User 1” can freely browse the content.
All those items were previously inaccessible to the user, outside the urbackup, on the PC itself.
Hopefully this explains the behavior, not sure if logs are needed for that but I guess if can provide them, but I need to know where they are and where to send them.
I installed the app as a “domain admin” (local users technically should not be able to install apps, so I need to use the admin account) but that should not matter I think, because the admin should be able to back up everything, but a regular user should not be able to access items that originally he didnt have permissions to.
In many cases, a backup needs to be done from everything on the machine, like the image, but it the restore process the one that has to be restricted, I guess.
I dont mean harm, urbackup is great, and Im thinking that I would install the clients so they backup only the document folder belonging to only one user on the machine (the one that uses most of the times), and not anybody elses.
That would protect a little the other users, and the admins.
You mean “restart” and then “log in as regular user” ?
I dont have the regular user credentials, I guess I could create one extra user and test.
In any case, the regular user should not even touch the tray icon (I was planning to ultimately install the app without tray icon via GPO)
This is a Domain environment, but since I saw this disclaimer on the web I didnt want to do it that way “LDAP/AD login is currently undergoing development and testing. Please do not expect it to work.”
The way I though was:
1- Install the Client on each PC so all PCs send backups to the urbackup server (to install client I need to be domain admin and I guess the client needs to run with enough rights over the PC so it can actually make images, etc)
2- Provide every user with credentials on the urbackup server so each of them can self-serve their restore needs. (since urbackup is not connected to AD, the credentials has to be local on urbackup server)
I though that urbackup could restore anything that was previously backed up, but keeping all permissions and attributes in files and folders.
I know it might be a complicated task, because if the user access urbackup web from another machine, connected on the network but outside the domain, the permissions on the restore files wont match, and could cause problems. or even the user could restore everything and then take ownership of the files.
I wonder how other backup solutions works on that.
The only thing I know is that the way Im testing, a regular user can restore files from some other user’s profile and see them.
I too am concerned here. I don’t have the option to use UrBackup connected to LDAP for Authentication and Authorisation etc.
Ideally I’d like the agent on the PC to run as the logged in user, and for only the data they can access to be backed up to the server. Then if another user logs in, (possibly multiple concurrent logged in users) the agent should only backup the files and content that the logged in users can access. perhaps what we need to look at is having each logged in user authenticate at least once with the UrBackup server, before backups can be attributed to that UrBackup user relative to the specific PC they are logged in to.