topic Re: System security in Operating System - OpenVMS

System security

Sumant M Kumar — Tue, 01 Dec 2009 06:06:36 GMT

Hi,

I need to set delete permission for test user who belongs to group [200,*].There are four test users in [200,*] group test,test1,test2 & test3.There is file SYS$SYSROOT:[SYSMGR]apps.com and permission is as below
$ dir/sec SYS$SYSROOT:[SYSMGR]apps.com
Directory SYS$SYSROOT:[SYSMGR]
apps.com;1 [SYSTEM] (RWED,RWED,RWED,RWE)

Now i need to set Delete permission for the user test but not for all the group so for that i used ACL but still i am unable to delete apps.com file.

$set security/acl=(identifier=[test],access=read+write+execute+delete] apps.com

When i logged in as test user and tried to delete the file its throwing errro "insufficient privilege".

Could you please suggest me if i need to use any ACL qualifier.

Regards,
Sumant

Re: System security

Steven Schweda — Tue, 01 Dec 2009 06:21:35 GMT

It might help if we could see the output from
a new "dire /secu" command. Also, the actual
"delete" command (and its actual error
message).

Re: System security

Steven Schweda — Tue, 01 Dec 2009 06:52:59 GMT

One other likely problem. As the HELP says:

DELETE

file

Deletes one or more files from a mass storage disk volume.

Requires delete (D) access to the file and write (W) access to
the parent directory. If the target file is itself a directory,
the directory must be empty.
[...]

Write access to the file's parent directory?

Re: System security

Jon Pinkley — Tue, 01 Dec 2009 06:57:36 GMT

To delete a file the process must have delete access to the file (in your case APPS.COM) and also write access to the directory that the file is in, in your case sys$sysroot:[000000]sysmgr.dir

If what you are showing us is actual output, that file will be

sys$specifiec:[000000]sysmgr.dir

or to determine absolute path:

$ TOPSYS = F$TRNLNM("SYS$TOPSYS")
$ DIR/SEC SYS$SYSDEVICE:['TOPSYS']SYSMGR.DIR

I would recommend moving APPS.COM out of SYS$MANAGER. In general it is best not to hand out write access to this directory.

See the guide to system security - chapter 8.

Re: System security

Robert Gezelter — Tue, 01 Dec 2009 08:55:30 GMT

Sumant,

As has been noted, access to the directory is required so that the file's directory entry can be removed.

Please note that this is a good reason to move such files out of the SYS$SYSROOT:[SYSMGR] directory. Giving a user sufficient access to manipulate this file ALSO gives them sufficient privilege to disrupt that directory.

Since that directory is critical to system operation, I would strongly counsel movbing that file to a different directory. This prevents accidental collateral damage.

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

Re: System security

Hoff — Tue, 01 Dec 2009 13:54:48 GMT

You will want to consider the use an OpenVMS resource identifier here in preference to the current UIC-based approach being discussed; resource identifiers are more flexible and more manageable, and can easily be configured (for instance) across UIC groups.

Here's a short write-up on how to set up a resource identifier and the related security and (if needed) disk quotas for a shared project directory:

http://labs.hoffmanlabs.com/node/1450

This example shows delete access for the resource identifier. In your specific case, you'd likely look to remove that access from both the default protection ACE and the protection ACE, and to add a parallel default protection ACE and protection ACE for the specific user (or probably better, for a user with a specific identifier) that allowed delete access. These two ACEs almost exactly parallel the ACEs shown in the cited example, though would be for, say, FOO_MANAGE identifier.

OpenVMS resource identifiers differ from standard security identifiers in the assignment of ownership and the ability to associate (if needed) a disk quota entry with identifier.

Re: System security

John Gillings — Tue, 01 Dec 2009 20:45:05 GMT

Sumant,

To diagnose any file manipulation command which fails with "insufficient privilege",
open a new window and enable it as a security operator console (needs OPER and SECURITY privilege)

$ REPLY/ENABLE=SECURITY

Now enable audit alarms of file access failures:

(needs SECURITY privilege)

$ SET AUDIT/ALARM=ENABLE=FILE=FAIL=ALL

Now repeat your failing command.

This should generate an audit alarm telling you exactly which file is failing, what type of access has been requested, and why it's failing. It's often not the file you think it is.

Re: System security

Sumant M Kumar — Wed, 02 Dec 2009 07:47:11 GMT

Thanks for your all suggestions now i am able to delete the file as a test user.I set the (g:rwed,w:re) permission on sysmgr.dir directory and also set the acl for the test user.
Directory SYS$SYSROOT:[SYSMGR]
Apps.com;1 [SYSTEM] (RWED,RWED,RWED,RWE)
(IDENTIFIER=[TEST],ACCESS=READ+WRITE+EXECUTE+DELETE)

Regards,
Sumant

Re: System security

Joseph Huber_1 — Wed, 02 Dec 2009 08:54:02 GMT

Just a side note:
Apps.com;1 [SYSTEM] (RWED,RWED,RWED,RWE)
has WORLD WRITE access!
I hope this is not the default protection of the owner SYSTEM !
Check with SHOW PROTECTION.

Re: System security

Sumant M Kumar — Wed, 02 Dec 2009 09:26:15 GMT

Thanks Joseph for letting me know about that.Yes you are right now i have removed the write permission from world.

$ dir apps.com/sec
Directory SYS$SYSROOT:[SYSMGR]
APPS.COM;1 [SYSTEM] (RWED,RWED,RWED,RE)
(IDENTIFIER=[TEST],ACCESS=READ+WRITE+EXECUTE+DELETE)

Regards,
Sumant

Re: System security

Wim Van den Wyngaert — Wed, 02 Dec 2009 09:40:26 GMT

Group users still have rwed. You said 1 user only so the d should go too.

Wim

Re: System security

Jan van den Ende — Wed, 02 Dec 2009 10:19:51 GMT

Sumant,

please, PLEASE read (and follow) the advise by Bob G (also hinted by Jon P) about MOVING ANY NON-OS stuff AWAY from [SYSMGR] (and all other SYS$SYSROOT directories) !!!

I have seen DISASTROUS thing happen by it!!

success.

Proost.

Have one on me.

jpe

Re: System security

Hoff — Wed, 02 Dec 2009 13:45:19 GMT

Yes, stay clear of SYS$SYSROOT.

It's a certainty that the SYS$SYSROOT searchlist does not work as might be expected. There are all manner of corner cases lurking within searchlists that can trip up even the most experienced of OpenVMS programmers. Files aren't necessarily where you might expect, and multiple directories must be created or you can get errors you might not expect.

Use your own top-level directory.

Re: System security

Peter Zeiszler — Wed, 02 Dec 2009 15:45:20 GMT

You really really want to move user stuff out of the main system directory. One wrong slip up and you may end up rebuilding a broken system.

Do you have another disk that it can be moved to? Show dev D

Re: System security

Sumant M Kumar — Thu, 03 Dec 2009 03:03:51 GMT

Hello Guru's,

I have moved the file from system disk to data disk(DKA100) and revoked the default permission on dka5:[sys0]sysmgr.dir

Now i have a better idea about ACL and setting permissions on dir/users & files and impact if i set wrongly on system directories.Thanks a lot for your valuable time and guidance.

Regards,
Sumant