Security
cancel
Showing results for 
Search instead for 
Did you mean: 

Switching from base to enhanced security questions

SOLVED
Go to solution
Sunil Gajraj
Occasional Advisor

Switching from base to enhanced security questions

We have servers in Production (both 5.1a and 5.1b, none using NIS, and non-clustered) which we would like to upgrade from base to enhanced security.

Can anyone help me with the following:

1. Would existing users' file access rights be affected in any way?
2. Would cron jobs be affected in any way?
3. Are there any differences between the 5.1a and 5.1b installations of enhanced security?
4. Are there any issues with Oracle installations on the servers?

Note that the required subsets are already installed...

Thanks,
Sunil.
5 REPLIES
Ann Majeske
Honored Contributor

Re: Switching from base to enhanced security questions

1. Would existing users' file access rights be affected in any way?
Not to existing files, but the default umask is more stringent with Enhanced Security. So, new files being created may have more stringent file permissions. You can mostly avoid this by resetting the umask in the users startup file (e.g. .login or .profile) but some applications (e.g. ftp) don't read the startup file.
There are also possible differences if you enable Access Control Lists as part of the security setup. Just answer NO to the question about enabling Access Control Lists (ACLs) to avoid this.

2. Would cron jobs be affected in any way?
Not sure what you mean by this. There is a question about setting up a crontab entry to trim the log file (which I recommend, the log file will just keep growing if you don't trim it periodically). Depending on how you answer this this question it will add an entry to root's crontab to trim the log file.

3. Are there any differences between the 5.1a and 5.1b installations of enhanced security?
I don't remember exactly, but I don't think there are any significant differences.

4. Are there any issues with Oracle installations on the servers?
I have no idea, I haven't done an Oracle installation on a system with Enhanced Security. The two most likely issues would be if Oracle accesses user password information (the password information is in a different file) or issues with files being created with file permissions that are too stringent such that users or applications that need access don't have access to the files (because of the default umask).
Sunil Gajraj
Occasional Advisor

Re: Switching from base to enhanced security questions

Thanks Ann. Your responses have been very helpful.

My question about cron jobs is really if existing jobs would be affected, e.g., I have the oracle user running nightly backups of the database and was wondering if there would be any access issues to the backup scripts...

- Sunil.
Sunil Gajraj
Occasional Advisor

Re: Switching from base to enhanced security questions

One more question - What would the fallback be if I wanted to revert to base security? Would it be simply changing it back in secconfig?
Ann Majeske
Honored Contributor
Solution

Re: Switching from base to enhanced security questions

If you're thinking about changing your production environment it is always best to test on a test or backup environment if you can. There may be unique configuration issues with your environment that we can't see or there may be issues that we just didn't know about or forgot about.

There shouldn't be issues with existing cron jobs accessing existing files, but there could be issues with new files that are created because of the change to the umask. This could impact files that are updated because some applications overwrite files with a copy rather than updating them in place.

Looking at secconfig there's a couple more items that you should be aware of. On the same screen that allows you to enable Access Control Lists ("Security-related system configuration options") there are two other items:
1) Segment Sharing
Segment Sharing is enabled by default in both Base and Enhanced Security. You can read section A.2.1.2 Segment Sharing in the Security Administration guide (http://h30097.www3.hp.com/docs/base_doc/DOCUMENTATION/V51B_HTML/ARH95ETE/TITLE.HTM) for an explanation. To enable/disable segment sharing secconfig sets the vm_segmentation subsystem attribute in the vm subsystem, see the sys_attrs_vm manpage. It looks like DISABLING segment sharing could cause access issues as well as excessive memory use, so I'd leave this one as-is (enabled).
2) Execute bit set only by root
Enabling this does just what it says, only allows the execute bit to be set by root. This one is disabled by default in both Base and Enhanced Security. To enable/disable execute bit set only by root secconfig sets the noadd_exec_access attribute in the vfs subsystem, see the sys_attrs_vfs manpage for more info. I'd leave this one alone too, unless you have a specific need for it.
To enable/disable Access Control Lists (ACLs) secconfig sets the acl_mode attribute in the sec subsystem, see the sys_attrs_sec manpage for more info.
You can always go back and change these settings at any time (either through secconfig or by setting the subsystem attributes directly) without changing the security mode. Changing some of them may require a system reboot.

You should be able to just run secconfig to revert to Base security. A few cautions
- Any time that you run secconfig to change the security mode you will have to reboot the system.
- All of your users will probably have to change their passwords, so you probably won't be the most popular person in the company if you change the security mode.
- You should make a note if you change any items from the default on the "Security-related system configuration options" screen when you go to Enhanced Security so that you can change them back properly if/when you revert to Base security.

Ann
Sunil Gajraj
Occasional Advisor

Re: Switching from base to enhanced security questions

Thanks again Ann.

Don't worry, I'll be testing the change to enhanced security on a couple of test machines.

We don't have too many users directly accessing these boxes, so we'll just verify the umask on the existing user profiles. Plus we've limited logins to only sysadmins and only via SSH.

I've seen the points noted on segment sharing and 'execute bit set only by root' in the security admin manual, so I will be taking note of these when I do test the change.

Regards,
Sunil.