Can you confirm the time frame aiming at 2011Q1 as GA release date?
This is a serious issue for hosting centers where different customers are backing up to the same NetWorker server. Even in non-hosting environment some customers are not willing to accept the security drawback introduced with NMM.
Yes.. NetWorker is introducing a lot of security stuff on one hand (encryption, certificates, etc).. But forgetting to address the most inportant issues.
It's like securing your house from intruders by blocking all windows .. And then leaving the front door open :-/
I have complained about this the last two years. I always feel like nobody worries about this. I think this is ridicilous error in privilage control.
This security also applies to all oracle clients, you need to specify a user of the oracle system on the admin list on NetWorker. That user has therfor super user access to NetWorker through nsradmin. For some companies it might be ok but not in a big distributed data zone.
Also, all the users can query the media db, even though they are not on the admin list juar by running mminfo -s . I think that is almost as big security hole. There is a workaround for that, but that poses other problems so we cant use it.
I think one of the most serious thing EMC should fix in NetWorker today, is the privilage control not being granular enough. But I think EMC has not got enough pressure to do anything about this.
Could try the following as a workaround. Please test in the lab first.
On the NW server side - instead of adding a carte-blanche *>@<vss_client_host just add 'administrator'@
Where:
'administrator' is the username under which the process that wants to do all powersnap related save operations which include deleting the mmdb records runs.
A caveat when doing the above is that - it has to be made sure that no other 'user' on that client host <vss_client_host> should be part of the 'NT administrator group (These are the windows administrator group - nothing to do with NW server usergroups)- on the Windows vss client
A slightly more safer solution would be to:
Create a special user on the <vss_client_host> -with the username 'vssclient_user'
Make 'vssclient_user' a member of the windows 'administrators' group on the vss_client_host side. è (The only reason for this condition - is that in case that vssclient_user needs to do certain things - such as create, modify or delete any local files on the vss_client_host as part of the power snap's operation - they can do so - without being stymied by Windows permissions.)
Add vssclient_user@ on the NW server's admin list (which is basically the 'administrator' attribute of the NSR resource on the NW Server RAP DB)
Advantages of this scenario:
namely 'vssclient_user' would be able to do all operations with all NW server privileges allotted.
No change in powersnap code
In the event a bunch of <'vss_client_host'> 'users' need to be able to do these operation(s) (of being able to delete mmdb records) then each of those ' @ ' could be added to the NW server side "administrator list" - and that is still better than *@ being added.
Dis-advantages of this scenario:
being able to do many things on the NW Server' (i.e. *@ to just one 'userid' (namely vssclient_user) being able many things on the NW server.
An *internal* malicious user could login as vssclient_user -and can do many operations on the NW server - only those pertaining to whatever is currently being done.
As you mention it is still not a water proof solution since local users on one host can gain full control of the NetWorker environment with a relatively small effort :-/
How can I add our NMM customers to the existing RFE on the issue?
If this is due to PowerSnap I do not know how will this be fixed. I run PS and in my case this is not an issue as I use it on UNIX boxes and UNIX admin sits next to me. Catch with PowerSnap is that it uses proxy servers to mount snapshot and since backup is done from there then storage node has to impersonate client (which means you must add client to server's file on storage node for example) and obviously index/admin permissions need to be altered. Now, this can be easily addressed by altering auth mechanism and permissions with some additional files to give this specific access. I guess that would be the way to address RFE. But what I find more interesting is the fact that most likely you do not use PS component with proxy so seeing this error (or requirement) should not take place in first time (thus addressing it would be much easier by adjusting existing code).
The fact that this security issue is because of PS does not make it any less serious problem. Our NMM clients are not using proxy's. Just the NMM code to backup applications and filesystem.
Again, this is also an issue with NMO and NMDA. And yes, I know it's because RMAN needs this privilages to manage the media.
That's great news. Can you tell me if this is going to be changed with Oracle (NMDA) clients? Will they still need to have a user on the administrator list on the datazone?
I have been told that NMDA and NMSAP do not require the admin privilege for backup and recovery. NMM checks some privileges before they start a backup (and requires admin priv)- NMDA and NMSAP does not. NMDA and NMSAP might require additional privileges for advanced type operations, like RMAN catalog synchronization- but for the typical work flows, NMDA and NMSAP should be fine. Check out the pic below or NMDA 1.1 administrator guide on page 60. Are you seeing something different?
jstamp
88 Posts
0
August 6th, 2010 09:00
Hello Mikkel,
Thanks for your question.
The privilege is a requirement from the Powersnap component in NMM, (not NMM itself), therefore at this time there is no work-around.
I will provide updates to this issue in this forum.
Thanks.
John
MKA1
4 Posts
0
August 9th, 2010 01:00
Hi John
Thanks for your input.
Can you confirm the time frame aiming at 2011Q1 as GA release date?
This is a serious issue for hosting centers where different customers are backing up to the same NetWorker server. Even in non-hosting environment some customers are not willing to accept the security drawback introduced with NMM.
Any fix earlier would be much appreciated.
Best regards,
Mikkel Kjaer Andersen
joka2
144 Posts
0
August 9th, 2010 06:00
I like your metaphor with the window and the door.
I have created a RFE ( request for enhancement) last year.
The more people that do, the more pressure EMC will have to fix this.
Johannes
MKA1
4 Posts
0
August 9th, 2010 06:00
Hi Johannes
Yes.. NetWorker is introducing a lot of security stuff on one hand (encryption, certificates, etc).. But forgetting to address the most inportant issues.
It's like securing your house from intruders by blocking all windows .. And then leaving the front door open :-/
//Mikkel
joka2
144 Posts
0
August 9th, 2010 06:00
I have complained about this the last two years. I always feel like nobody worries about this. I think this is ridicilous error in privilage control.
This security also applies to all oracle clients, you need to specify a user of the oracle system on the admin list on NetWorker. That user has therfor super user access to NetWorker through nsradmin. For some companies it might be ok but not in a big distributed data zone.
Also, all the users can query the media db, even though they are not on the admin list juar by running mminfo -s . I think that is almost as big security hole. There is a workaround for that, but that poses other problems so we cant use it.
I think one of the most serious thing EMC should fix in NetWorker today, is the privilage control not being granular enough. But I think EMC has not got enough pressure to do anything about this.
Johannes
rochem1
23 Posts
0
August 9th, 2010 07:00
Could try the following as a workaround. Please test in the lab first.
Where:
A caveat when doing the above is that - it has to be made sure that no other 'user' on that client host <vss_client_host> should be part of the 'NT administrator group (These are the windows administrator group - nothing to do with NW server usergroups)- on the Windows vss client
A slightly more safer solution would be to:
Advantages of this scenario:
Dis-advantages of this scenario:
MKA1
4 Posts
0
August 11th, 2010 02:00
Hi Michael
Thanks for your input on tightening security.
As you mention it is still not a water proof solution since local users on one host can gain full control of the NetWorker environment with a relatively small effort :-/
How can I add our NMM customers to the existing RFE on the issue?
Best regards,
Mikkel
joka2
144 Posts
0
October 19th, 2011 08:00
Hi.
Does anyone here have the RFE number for this issue?
Regards,
Johannes
ble1
4 Operator
•
14.4K Posts
0
October 23rd, 2011 14:00
Didn't you say few posts away you have created one??
joka2
144 Posts
0
October 25th, 2011 04:00
That is correct, I had problems finding it in my email. But I found at last in my powerlink SR system.
The ID is RFE NW00103312
Regards,
Johannes
ble1
4 Operator
•
14.4K Posts
0
October 26th, 2011 10:00
If this is due to PowerSnap I do not know how will this be fixed. I run PS and in my case this is not an issue as I use it on UNIX boxes and UNIX admin sits next to me. Catch with PowerSnap is that it uses proxy servers to mount snapshot and since backup is done from there then storage node has to impersonate client (which means you must add client to server's file on storage node for example) and obviously index/admin permissions need to be altered. Now, this can be easily addressed by altering auth mechanism and permissions with some additional files to give this specific access. I guess that would be the way to address RFE. But what I find more interesting is the fact that most likely you do not use PS component with proxy so seeing this error (or requirement) should not take place in first time (thus addressing it would be much easier by adjusting existing code).
joka2
144 Posts
0
October 27th, 2011 03:00
The fact that this security issue is because of PS does not make it any less serious problem. Our NMM clients are not using proxy's. Just the NMM code to backup applications and filesystem.
Again, this is also an issue with NMO and NMDA. And yes, I know it's because RMAN needs this privilages to manage the media.
But other vendors don't have this issue.
Regards,
Johannes
AllanW1
334 Posts
0
October 27th, 2011 10:00
Hi Johannes,
This is currently being resolved in the next release of NMM.
Allan
joka2
144 Posts
0
November 2nd, 2011 08:00
Hi Allan.
That's great news. Can you tell me if this is going to be changed with Oracle (NMDA) clients? Will they still need to have a user on the administrator list on the datazone?
Regards,
Johannes
AllanW1
334 Posts
0
November 3rd, 2011 08:00
Hi Johannes,
I have been told that NMDA and NMSAP do not require the admin privilege for backup and recovery. NMM checks some privileges before they start a backup (and requires admin priv)- NMDA and NMSAP does not. NMDA and NMSAP might require additional privileges for advanced type operations, like RMAN catalog synchronization- but for the typical work flows, NMDA and NMSAP should be fine. Check out the pic below or NMDA 1.1 administrator guide on page 60. Are you seeing something different?
Thanks,
Allan