limiting file and directory access to a group of users

[Kevin Carter_3]

User Fred owns a directory with several sub directories, for example:

usr$disk1:[fred]
usr$disk1:[fred.data...]
usr$disk1:[fred.shared...]
usr$disk1:[fred.private...]
usr$disk1:[fred.stuff...]
usr$disk1:[fred.morestuff...]
...

Fred wants to allow 3 customers to log in with their own accounts and be able to read but not alter or delete any files in usr$disk1:[fred.shared...] and restrict access to any directories or files above the "shared" directory.

The 3 customer accounts have the default login directory set to usr$disk1:[fred.shared] and the customer accounts are in the same OS user group as fred.

What is the easiest way from a sysadmin perspective to restrict / allow access to the directories & files? Group file permissions, ACL's, other...

The Operating system is OpenVMS 8.2 Alpha.

Thanks for the input

Kevin

[Robert Gezelter]

Kevin,

The OpenVMS Guide to System Security contains the information you will need.

Basically, one adds an Access Control List permitting the desired access on the directory and the files desired. One can also get sophisticated and set default ACLs for newly created files on a directory by directory basis.

In this case, a quick verification confirms that EXECUTE access is needed on [fred] and [fred.shared]. READ access will be needed on the actual files to be read.

The older command would be SET ACL. The more current command is SET SECURITY. I suggest reviewing the documentation in both the HELP text and in the documentation set before adjusting ACLs.

I hope that the above is clear. If I have been unclear, please let me know.

- Bob Gezelter, http://www.rlgsc.com

[Jon Pinkley · Accepted solution]

Kevin,

ACLs are the only way to get the granularity of access you want, especially if there are other members of the UIC group besides fred and the 3 customers.

One way to allow the three customers read only access to the files in the [.sharedâ ¦] tree that are owned by fred, would be to create a new identifier (this requires privilege) and then grant that identifier to the three customers.

Do read the relevant parts of the manual Bob referenced.

Something like the following (this is without testing, caveat emptor, use at your own risk, etc.)

$ mcr authorize
UAF> create/id fred_shared
UAF> grant/id fred_shared customer1
UAF> grant/id fred_shared customer2
UAF> grant/id fred_shared customer3

This assumes that the three customers have unique UICs

I assume that the users won't be getting VMS mail, since you have placed them in a directory that they have not write access to.

Then set up the ACL on the [fred]shared.dir file to allow read access to identifier fred_shared

$ set security/class=file -
/delete=all - ! add this to remove any previous ACL from file
/acl=((identifier=fred_shared,access=read), - ! this allows them to see file names
(identifier=fred_shared,options=default,access=read), - ! this applies to files created
(default_protection,system:rwed,owner:rwed,group:,world:)) -
/protection=(s:rwed,o:rwed,g:e,w:e) /owner=fred -
usr$disk1:[fred]shared.dir
$ set security/like=name=usr$disk1:[fred]shared.dir usr$disk1:[fred.shared...]*.dir ! set the rest of the lower directories the same
$ set security/default user$disk1:[fred.shared...]*.*;*/exclude=*.dir ! set all the files

Jon

[Kevin Carter_3]

Both suggestions were valuable, the first pointing me to the documentation; teaching me to fish. The second giving examples of how to.

[Hoff]

I'd also look for other approaches here too, as allowing a customer access onto the server can allow read or SHOW SYSTEM or other access further into the box.

Possibly an ftp or sftp service, or an outboard disk server, or via web services. Or you can restrict access with a captive username and a DCL menu; you can keep the folks tied down and controlled.

[Doug Phillips]

I would definitely follow Hoff's suggestion of restricting them to a menu or sandbox DCL environment.

I would also give them a sys$login other than [fred.shared] to hold their login.com (and any generated .log files) so that the only files in the shared directory are files they can access.

[Jon Pinkley]

Kevin,

Just so there is no confusion about what the commands I outlined in my Nov 4, 2009 01:02:43 GMT post do, I need to state the following:

The ACL on the shared.dir file does nothing to limit the customers' access to any files above it, or anywhere else on the system. It assumes that the customer accounts have no access to any files they should not, and explicitly grants them access to files that they would otherwise not have access to.

In other words, if there is a usr$disk1:[000000]joe.dir that has world read, and files in it have world read protection, then the customers will be able to read those files. Likewise if fred doesn't protect the files in his [.private] directory, then they will also be accessible to any process that is allowed access.

Some ftp servers can limit access to files in a specific directory tree, but in that case it is the ftp server acting as a proxy, that is limiting the access to files in a specific directory tree.

As far as I know, in standard VMS there is no way to limit what files a use can request to be opened. Specifically,

UAF> modify customer1 /device=usr$disk1: /directory=[fred.shared]

has absolutely no effect on what files customer1 can access. It only provides a default for the process when the account logs in. (and even the /device portion can be overridden at login time, see help login)

VMS uses a discretionary security model; the owner of the files determines what has access to them, and certain privileges can override any limits that these protections specify. For example, READALL allows read access to any file, and BYPASS allows unrestricted access regardless of any file protections or ACLs.

Before allowing access to a customer, you should get management approval, and then have a knowledgeable VMS person log into the account that will be given to the customer, and have them try to see what they can access while you are watching. There are also software products to find potential problems by looking at file protections, privileges, etc.

Depending on the purpose of access to the files, and risks involved if other data is exposed, you may want to duplicate the data on a completely different system meant only for external access. If the customers will be doing a specific task that can be easily contained in a command procedure, then using a captive account (i.e. UAF> modify/flag=(captive) customer) with a secure login command procedure will add a layer of security. However, doing that correctly will require someone with VMS knowledge.

As Steven Schweda says "Everything's complicated."

Jon

[Kevin Carter_3]

Thank everyone for the follow up responses about security, really appreciate the extra effort. Here is what I did to lock down the 3 accounts that need to look at files in usr$disk1:[fred.shared...].

Created an identifier named fred_review
Granted the ident to each of the 3 users
Changed the group uic of each of the 3 accounts so they are not part of fred's group.

set sec/acl=(ident=fred_review,access=read) /class=file usr$disk1:[fred]shared.dir

set usr$disk1:[fred.shared...] so the acl will be applied to new files

modified the existing *.dir
modified the existing files

tested the accounts by logging in and trying to do a $ set defa [-] once then twice.

got an insufficient privileges or protection violation, so unless I am overlooking something I think the problem has been addressed -

[Jon Pinkley]

RE:"tested the accounts by logging in and trying to do a $ set defa [-] once then twice.

got an insufficient privileges or protection violation, so unless I am overlooking something I think the problem has been addressed -"

Ok, so you checked that the front door appears to be locked. However there may be other doors and windows you haven't checked.

Seriously, you need to think like a hacker when you are testing. And the amount of testing needed depends on the value of what you are trying to protect. I am sure this solution would no be acceptable in many environments, but it may be for yours.

Think about this. Is there any information that is accessible to your employees that you do donâ t want your customers to see? If so, how is that information protected from the customer accounts?

Jon