Showing results for 
Search instead for 
Did you mean: 

Enhanced Security

Go to solution
Patrick Giblett
Occasional Contributor

Enhanced Security

Does anyone know how to convert a Tru64 (V5.1A) from base security to enhanced security without invoking the security gui.

I wish to do the conversion as part of the installation of a turn key system by means of scripts invoked from the 'postload' script run as part of a 'configured' install
Ralf Puchner
Honored Contributor

Re: Enhanced Security

first post the question next time in the right section: security

the gui is also available within textmode, other possibility is to install with autoanswer install file (have a look into the installation manual and c2 manual).
Help() { FirstReadManual(urgently); Go_to_it;; }
Patrick Giblett
Occasional Contributor

Re: Enhanced Security

I do not wish to allow the user/installer to interact with the security setup so the textmode gui tool is no applicable. The only documented way to change the security levels is to use the seconfig or the sysman seconfig commands which are interactive

If by an auto answer file you mean a precanned set of answers I need to know which program(s) to run. if it is Sysma seconfig then how to i precan all the navigation commands is there a keystoke captue utility that I can pipe through that passes the arrow keys?

I have tried generating a 'config.cdf' file from a configured system bu this did not carry over the C2 security aspects.

Kris Smith

Re: Enhanced Security


Installing Enhanced Security should be performed by a security or system administrator, and typically all of the machines in a given system are configured by the same administrator/team. Installation of the Enhanced Security may require kernel builds, reboots, and will certainly involve management of the default directory and file permissions. If you allow users to set these defaults you may be defeating the purpose of the elevated security configuration.
From experience I can tell you that you will likely spend more time trying to "can" the installation versus planning the security strategy and then performing a one-time installation and configuration. This also affords the system or security administrator the opportunity to verify that the installation was correct and that things are working properly. An improper Enhanced Security installation can render a production machine nearly useless until it has been corrected.
Kris Smith

Re: Enhanced Security

By the way, regardless of the method you choose to configure the enhanced security, you should take Ralph's advice and read the Tru64 UNIX Security manual, Part Number AA-Q0R2E-TE (Tru64 UNIX Version 4.0F or Higher)
Patrick Giblett
Occasional Contributor

Re: Enhanced Security

In our application the target hardware is turnkey. There is no qualified security manager to perform the setup. The security has to be in place from the start of the installation.

I have read the security manuals and there is no reference to seting the security level other than by using the X or textbased GUIs

There is an oblique reference to the comandline methods having been disabled/removed.
Ann Majeske
Honored Contributor

Re: Enhanced Security

Hi Patrick,

I asked our Enhanced Security experts and here's what I got back. Since this is cut-n-pasted from replies to previous queries some of it may not apply to you. Note that in addition to just turning on Enhanced Security you need to configure it appropriately for your needs, so it would be a good idea to read the Security manual to get information on configuring Enhanced Security. It would also be a good idea to try enabling Enhanced Security using the GUI on one system so you get the feel for the configuration information that it asks for and how you want to set things up.

One last thing, for V5.1A it would be best to install the bl24 kit (patch kit 6) as it fixes some problems with mmapped files and Enhanced Security uses mmapped files. But, you'll also have to make sure to get the ERP for the find problem that exists in patch kit 6.


To "cheat" and apply the conversion to Enhanced Security 'by hand' rather
than using sysman secconfig, do the following. They might want to run
secconfig once to see
what all it asks and offers, since it handles some sysconfigtab settings
in addition to 'just' doing Enhanced Security. (Those are
vm:vm_segmentation and sec:acl_mode if I recall correctly.) Once any
related sysconfigtab settings are identified, though, they can just do
those 'by hand' too on the other systems.

The recipe for doing ES (Enhanced Security) 'by hand' is this:

# convuser -ai
# rcmgr -c set SECURITY ENHANCED
# /sbin/init.d/security start
# /sbin/init.d/sia start
# passwd root

If CDE is in use, then add this:

# /sbin/init.d/xlogin restart

A full reboot is actually recommended, but the above is the minimum to get
things going. I suspect that sshd would also have to be stopped and
re-started, though, and there may be other such daemons. [Not being able
to be sure of the complete list is *why* we recommend the reboot.] Not
'bouncing' CDE means that a locked screen-saver requires some other means
of getting back into the machine, however, which is why that one's
essential if deferring the reboot.

This is obviously all a lot easier if done as part of initial configuration.

Oh, yeah. With that many machines, they may be wanting to configure NIS
to serve the authentication data. That's also best done early. If it's
done before they have a real user community, it's really easy. The
Security book should have a decently accurate description of setting that
up, though. I recommend the use of the /var/yp/securenets file (described
only in the ypserv(8) manpage, rather than one of its own), but I'm a
professional paranoid. [That manpage describes an /etc/yp/securenets
file, but follow the bouncing symlinks and it's where I said.]

I also strongly recommend running auditing. Not necessarily with the full
set of events that sysman audconfig would recommend, but having it in the
kernel and the daemon (auditd) running makes things a lot easier to use it
later, if suspicious activity is discovered. I'd really recommend setting
it up for the"trusted_event" category at a minimum, but running with *no*
events (esentially in 'hot-standby' mode) is better than not running it.

At one point, the Security book had an appending describing a 'real'
(Department of Defense "Orange Book") "C2" configuration. That's probably
still in the V5.1A version of the book, though maybe not in the V5.1B one.
They may want to examine that, mostly to be sure they've thought about
their overall security policy, and to see if that description makes them
think of anything else.

Also, depending on how many simultaneously-ongoing login or other
authentication attempts they might get on any of the systems, they might
need to disable prpasswdd. [It's possible for logins to fail from running
out of privileged UDP ports.] The supported way to do that (and one which
survives update install) is this:

# rcmgr -c set PRPASSWDD_ARGS -disable

That will print out complaints at system start-up, but the complaint is
harmless. They should only do that if they're going to hit the limit,
though (probably at around 200-250 simultaneous authentications in
progress). Otherwise, the use of prpasswdd helps alleviate some
congestion with accessing the auth.db files when they need to be updated.
[This aspect is sort of in the "known bugs" category, but it's not as
readily fixed as some others, and has no patches available.]

There are some things we may recommend, depending on the configuration. One is to disable the auth.db-based logging of successful
logins. I'm told that the instructions for doing that are wrong in the
Security book, though. That should look like something like this:

edauth -dd -g1 default |
sed -e 's/:/:d_skip_success_login_log:/' |
edauth -dd -s

This is really part of going over the system defaults data (from `edauth
-dd -g default') and being sure it all meets their security needs. One
example is the vacation settings (which are shipped disabled). Those are
often something sites should set up based on the company's handling of
employee vacations. [Those settings are d_max_vacation_future and
d_max_vacation_duration.] Another one is the unlock intervals (u_unlock
and t_unlock) - which ship set at 1 day (24 hours, alias 86400 seconds).
Many sites are better served by setting those to 7200 (2 hours).

Basically, they should be sure they have looked over the settings (and
their descriptions in the manpages) to be sure they have some idea what
they're enabling. Then, they should extract the edited record from the
first system where they apply the settings (`edauth -dd -g default'
again), and apply them on the others (`edauth -dd -s < settings').

Ralf Puchner
Honored Contributor

Re: Enhanced Security


due to prior version support of 5.1A it should be wise to install one of the latest version (5.1B/5.1B-1/5.1B-2) instead of using 5.1A.

Help() { FirstReadManual(urgently); Go_to_it;; }
Ann Majeske
Honored Contributor

Re: Enhanced Security

Hi Ralf,

I do agree that it would be better if Patrick upgraded to the latest patch kit on V5.1b. But the question was asked for V5.1a so that's how I answered it :) Also, V5.1a prior version support has been extended to 2007, so we're likely to be getting at least some v5.1a questions for the forseeable future.

The procedure I outlined in my previous response should be the same for V5.1a and V5.1b. There would be some differences for V4.0* systems, for example there is no prpasswdd on v4.0*.

Patrick Giblett
Occasional Contributor

Re: Enhanced Security

Thankyou Anne

That was the information I needed.

We are using 5.1A because that is the version that has been certified/acredited.

Auditing and other securty setups will be swept up in our automated installation (amazing how much one can do in a 'postreboot script)