FDL Security

[vmsserbo]

I need to investigate the current ownership and protection for files in the PROD_FDL directory on all of our 40 nodes.

I need to recommend a security standard that will work around the country while protecting the files at the highest possible level.

Has anyone done this on their sites?

For instance, if World does not have access to any FDL files on some of the nodes, I can guess that World probably does not need any access, and recommend that as a standard.

Is there a better command that I can use besides dir/sec?

This is what I get as an example

dir/sec Nodename::prod_fdl:
SYSTBMIS.FDL;5 [500,7777] (RWED,RWED,RWE,RWE)


Any ideas?

Thanks!

[Steven Schweda · Accepted solution]

> [...] I can guess [...]

It might make more sense to start by trying
to understand the access requirements for
these files, rather than assuming that the
existing protections actually make any sense.
(For example, why would W:RWE be better than,
say, W:RW?) You could save a lot of work by
guessing that everything's ok now, too, if
guessing is good enough.

> Is there a better command that I can use
> besides dir/sec?

I believe that you can get the owner-group
data from F$FILE_ATTRIBUTES. I don't know of
a handy way to get the security data.

[Hein van den Heuvel]

If the FDL files are indeed what the names imply then they are RMS File Description Files, used for production file re-creates or convert.

So they need to be readable by whatever username executes those creates/converts, and in that sense might as well have the same protection as the data files to be created

There is no valuable data - data in them, just meta data, so world read is fine, unless you feel the need to control idle curiousity.

World write is rather bad for those files, not because they can directly trash production data, but because of 'denial of service' potential. Anyone mucking with those files can leave a boobytrap for some future convert which may be months (years) away and then create an unusable data file.

You could argue that only development and a DBA style user can/should have write access to FDL files, NOT the operators / production support users using them.

Typically I would hope operators / production support is smart enough to be trusted with FDL and even allowed to make tuning changes (allocation, extent, bucketsize).

Cheers,
Hein van den Heuvel
HvdH Performance Consulting

[vmsserbo]

Thanks for the input I do agree with what your saying.

The way it stands now, most fdl protectons
are set like this

(RWED,RWED,RWE,RW)

I think I am going to recommend the following

(RWED,RWED,RWE,R)

Should the Group be able to have the "D" delete permission?

Your thoughts?

Thanks again!

[vmsserbo]

Thanks for all you help

I will follow the same protections scheme for our .fdl files as we have with our .dat files

(RWED,RWED,RWED,R)

Thanks and Happy New Year!

[Jim_McKinney]

> Should the Group be able to have the "D" delete permission?


Only you can answer this. Who is in the UIC group besides the owner? Do you want these other users to be able to delete these FDL files? If not, then you'll probably want to remove that potential.

[Hein van den Heuvel]

For me delete and write access to an FDL file are equivalent.

I don't think anyone (other than me :-) has ever used write access to an FDL file ever!

The main FDL (design) files should be safe in an CMS library.

The current FDL files can readily be recovered from the data files themselved and/or from the design + current statistics.
So they need no special protection IMHO.

fwiw,
Hein.

[DECxchange]

Hello,
Are you using FDL as in the standard VMS nomenclature, File Definition Language? It appears so given your example.

Another way to look at file protection and ownership is with the
$ dir/protection/owner command. But that pretty much tells you the same thing. You can also add the /file qualifier to get the file ID (that is useful mostly when you are dealing with operating system files).

Also, if you are to have a security standard for all of your 40 nodes, I would be concerned about the file protections and ownerships on your data files (.DAT or whatever they may be), executable (.exe), DCL command files (.com), source code files (if that applies on some or all of your nodes), and so forth. Also, I would be worried about who can access operating system and layered product files in the sys$system directory trees, sys$manager directory, and so forth.

Tyically, if you suspect that Group (g) and World (W) users may cause problems by modifying or deleting these files, you should take a look at the system and application overall to see who should have access.

You may may want to restrict access to operating system files to system administrators and network admins, application source files to certain programmers (depending on skill level and trust), and application executables and data files to authorized users, based on file ownerships and access control lists.

Anyway, that's just an general example and it could vary based on your site and application requirements. If I can be of any further help, let me know.

[Wim Van den Wyngaert]

I would check with dir/dat=mod if any of the files are modified recently. This could indicate that the files are modified by users or programs.

Many dcl scripts create the fdl file themself, e.g. during startup (at least over here). If there are any modified files you will have to find out who is doing it before you revoke the W access. You can set e.g. an acl on the file to get audit alarms (and thus find out who did it).

Fwiw

Wim