May the source be with you, but remember the KISS principle ;-)
Home Switchboard Unix Administration Red Hat TCP/IP Networks Neoliberalism Toxic Managers
(slightly skeptical) Educational society promoting "Back to basics" movement against IT overcomplexity and  bastardization of classic Unix

Conversion of Application and Adminitrative Accounts to Roles

News Role engineering Recommended books Recommended Links Solaris Profile Shells Solaris privileges sets Conversion of application accounts to Roles
user_attr prof_attr exec_attr auth_attr policy.conf    
Reference sudo vs RBAC   ACLs usage is roles Profile Shells Humor Etc

Role Based Access Control (RBAC) allows to create special accounts (called roles) that cannot be accessed via external login (for example telnet or ssh). It also permits unprivileged users to execute out privileged commands much like sudo.

A role is identical to a user account, except you can't log on to the system with a role user account and need to use su. Most applications will never understand the difference.

While RBAC is conceptually similar to sudo (actually pfexec command is an almost exact replica of sudo functionality) , but is more versatile and starting with Solaris 10 much more powerful.  But even in Solaris 8 and 9 it is an attractive solution for several security related problems including,  but not limited to:

One of the simple, yet important usage of RBAC is to control "application" accounts like "oracle", "webuser", "apache" etc. The idea is to convert a given account to a role and that automatically blocks all external logins.  This idea is far from being new, but still it is surprising how many enterprises do not use it.

You also need explicitly add the right to assume this role to accounts the need to su to it.

This procedure explains how to convert an application account to role on Solaris 8 and 9.  This is a better way to do this Solaris 10.

Converting an Existing Application and Administrative Accounts to Role

Step 1: Check if you are root. You need to be a superuser. We will use root as an example of conversion as it exists on any machine and most sysadmins can test this procedure directly on their personal Sun workstations. We will assume that the user joe_adm will be the account that is able to su to root. Other users can be added in a similar way.

Step 2: Backup existing authorization databases. There are four files that make up RBAC configuration:

Actually only /etc/user_attr needs to be backed up as this is the only file that is changed in this procedure.

Step 2: Edit the /etc/user_attr file.

Here is a relevant fragment from a typical user_attr file.


Note: if /etc/passwd file was copied from another server there might be some or all the users that are absent from this file. For consistency you might want to add them. Generally it's better to do this with a script that converts "human" accounts into records of the format, shown above.

  1. Edit the line for the account that you want to convert to role (root in our case) replacing type=normal with type=role. The result should be:


  2. Change shell on the root account to /usr/bin/pfksh . This is the shell that checks for the privileges assigned to the role (actually the same executable as /usr/bin/ksh, just a hard link to it).
  3. Verify that you cannot telnet/ssh to the account anymore (telnet check not make sense for root, as it is already blocked by other means). After you provided the id of the role and password, you should get a message that login failed because this account is a role, if you did steps 1-2 correctly.
  4. Add root to the roles that are assigned to all relevant users (none of the users that you are adding should be active on the server). For example to add it to user joe_adm you need

    usermod -R root joe_adm

    1. Verify that addition was successful in the /etc/user_attr :


    2. Su to one of the account that you added to the role

      su joe_adm

    3. Run command roles to verify that the user can accept this role

      # roles

Top Visited
Past week
Past month



[Feb 11, 2005] How To Create Custom Roles Using Based Access Control (RBAC)

#41168 How to set up RBAC to allow non-root user to manage in.named on DNS server

The following are assumed:

Configuration Steps

1. Create the role and assign it a password:

	# roleadd -u 1001 -g 10 -d /export/home/dnsrole -m dnsrole
	# passwd dnsrole

NOTE: Check in /etc/passwd that the shell is /bin/pfsh. This ensures that nobody can log in as the role.

Example line in /etc/passwd:


2. Create the profile called "DNS Admin":

Edit /etc/security/prof_attr and insert the following line:

	DNS Admin:::BIND Domain Name System administrator: 

3. Add profile to the role using rolemod(1) or by editing /etc/user_attr:

	# rolemod -P "DNS Admin" dnsrole

Verify that the changes have been made in /etc/user_attr with profiles(1) or grep(1):

	# profiles dnsrole
	DNS Admin
	Basic Solaris User
	# grep dnsrole /etc/user_attr             
	dnsrole::::type=role;profiles=DNS Admin
  1. Assign the role 'dnsrole' to the user 'dnsadmin':
  1. If 'dnsadmin' already exists then use usermod(1M) to add the role (user must not be logged in):
       # usermod -R dnsrole dnsadmin
  2. Otherwise create new user using useradd(1M) and passwd(1):
       # useradd -u 1002 -g 10 -d /export/home/dnsadmin -m \
       -s /bin/ksh -R dnsrole dnsadmin 
       # passwd dnsadmin
  3. Confirm user has been added to role with roles(1) or grep(1):
       # roles dnsadmi
       # grep ^dnsadmin: /etc/user_attr

5. Assign commands to the profile 'dns':

Add the following entries to /etc/security/exec_attr:

	DNS Admin:suser:cmd:BIND 8:BIND 8 DNS:/usr/sbin/in.named:uid=0
	DNS Admin:suser:cmd:ndc:BIND 8 control program:/usr/sbin/ndc:uid=0

If using Solaris 10 you may need to add a rule for BIND 9:

	DNS Admin:suser:cmd:BIND 9:BIND 9 DNS:/usr/sfw/sbin/named:uid=0

BIND 9 does not use ndc, instead rndc(1M) is used which does not require RBAC.

6. Create or Modify named configuration files.

To further limit the use of root in configuring and maintaining BIND make dnsadmin the owner of /etc/named.conf and the directory it specifies.

	# chown dnsadmin /etc/named.conf
	# grep -i directory /etc/named.conf
		directory "/var/named/";
	# chown dnsadmin /var/named

7. Test the configuration:

Login as the user "dnsadmin" and start named:

	$ su dnsrole -c '/usr/sbin/in.named -u dnsadmin'

To stop named use ndc (for BIND 9 use rndc):

	$ su dnsrole -c '/usr/sbin/ndc stop'


In this example the user 'dnsadmin' has been set up to manage the DNS configuration files and assume the role 'dnsrole' to start the named process.

The role 'dnsrole' is only used to start named and to control it with ndc (for BIND 8).

With this RBAC configuration the DNS process when started by user 'dnsrole' would acquire root privileges and thus have access to its configuration files.

The named options '-u dnsadmin' may be used to specify the user that the server should run as after it initializes. Furthermore 'dnsadmin' is then permitted to send signals to named as described in the named manual page.


ndc(1M), named(1M), rbac(5), profiles(1), rolemod(1M), roles(1),
rndc(1M), usermod(1M), useradd(1M)
root logins by preventing all users from logging in as root. Instead, they must log in as normal users prior to assuming the root role. See "Making Root a Role".

  • Single Role Only - This method adds the Primary Administrator role only and is similar to the superuser model.

  • Suggested Roles - Three suggested roles that can be easily configured are available: Primary Administrator, System Administrator, and Operator. These roles are suitable for organizations with administrators at different levels of responsibility whose job capabilities fit the suggested roles.

  • Custom Roles - You can create your own roles to meet the security requirements of your organization. The new roles can be based on existing or customized rights profiles.

  • Decide which suggested roles are appropriate for your organization.

    Review the capabilities of the suggested roles and default rights profiles. Three rights profiles are available for configuring the suggested roles:

    These rights profiles enable administrators to configure the suggested roles by using a single rights profile instead of having to mix and match rights profiles.

    To further examine rights profiles, use the Rights tool to display the contents. You can also refer to "Contents of Rights Profiles" for a summary of some typical rights profiles. With the console tools, you can customize the roles and rights profiles that are provided to meet the needs of your organization.

  • Decide if any additional roles or rights profiles are appropriate for your organization.

    Look for other applications or families of applications at your site that might benefit from restricted access. Applications that affect security, that can cause denial-of-service problems, or that require special administrator training are good candidates for RBAC.

    1. Determine which commands are needed for the new task.

    2. Decide which rights profile is appropriate for this task.

      Check if an existing rights profile can handle this task or if a separate rights profile needs to be created.

    3. Determine which role is appropriate for this rights profile.

      Decide if the rights profile for this task should be assigned to an existing role or if a new role should be created. If you use an existing role, check that the other rights profiles are appropriate for users who are assigned to this role.

  • Decide which users should be assigned to the available roles.

    According to the principle of least privilege, you should assign users to roles that are appropriate to their level of trust. Keeping users away from tasks that they do not need to use reduces potential problems.

    The Jail Chroot Project's purpose is to streamline the task of creating the chroot jail environment. It does so with utilities that "automagically configure & build all the required files, directories and libraries". It also makes adding new jailed accounts very easy. In this article, we'll take a look at the Jail Chroot Project utilities and show you how to install and use them to secure remote access accounts in a chroot-ed environment on your GNU/Linux system.

    The basic idea

    The Jail Chroot Project is the brain-child Juan M Casillas. On his web site, Juan explains how his utility works:

    "Jail is a login tool. It works as a wrapper to the user shell, so when a user logs into the machine, Jail is launched, and the chrooted environment is activated. Then, Jail executes the real user shell, so he gets his session in the server.

    The 'chrooted environment' is a subtree of the full tree in the filesystem, and the top of this subtree is viewed by the chrooted user as the root '/' entry of the tree. So Jail is useful for isolating users from the main filesystem's directory tree. As you can see in the diagram, the light-gray shaded boxes are the chrooted environment:"

    Any user configured to be chroot-ed using Jail (such as user3 in the diagram) will be changed to his home directory (light-grey shaded box labeled user3) when that user logs into the machine. The root directory will appear to that user as the tree under the "chroot" directory. That is, user3 will only can see the files under the directory called 'chroot', thus locking that account in the "chroot jail", safely away from vital system files.


    The installation of Jail Chroot is pretty standard *NIX fare. First, download the latest tarball (currently verion 1.9) at:

    Once downloaded, simply unpack it with the command:

    tar -zxvf jail_1.9.tar.gz

    This will create a "jail_1-9_stable" directory where you unpack the file. Change directories to the one just created and you'll find a "src" directory. This is where you'll compile the utilities. Be sure to check the Makefile for your platform (Linux is set as the default). Simply issue a "make" and then "make install" as root to compile and install the utilities. Once you've gotten this far, you're ready to create the chroot-ed environment.

    Creating the Jail

    Once you've installed the Jail Chroot package, you're can build the chroot-ed jail environement. You'll need to decide where to build this environment, so take into consideration your partition sizes. For the purposes of this article, we'll create the chroot jail in the /home/jail dirctory. To set it up, run the following command as root:

    /usr/local/bin/mkjailenv /home/jail

    After executing the command, you should see text ouput similar to the following:

    		Making chrooted environment into /home/jail
    		        Doing preinstall()
    		        Doing special_devices()
    		        Doing gen_template_password()
    		        Doing postinstall()

    Once complete, you've got a basic chroot environment installed in /home/jail. Now you'll need to add software for basic use in the jail.

    Installing Software

    The Jail Chroot utility adjailsw lets the system administrator choose between two methods of installing software for users in the jail. When your run the command without any arguments, addjailsw will add a default set of applications into the jail environment. To do this, run the following command as root:

    /usr/local/bin/addjailsw /home/jail

    This will install a group of basic commands for availablitilty in the chroot environment. These commands include some of the basics like ln, ls, mv, grep, cp, tail, touch and more. If you don't want to install the default set, you can use addjailsw with the -P option to specify each software package you want installed one by one in the chroot jail. For example, let's say you want to install the text editor joe. As root, just run the command

    /usr/local/bin/addjailsw /home/jail -P joe

    This will install joe for the chroot environment.

    Adding inmates

    Once you've added the software for your chroot environment, all that's left is to create user accounts. Prior to creating a user to the jail, you'll need to add him to your system in the normal fashion with adduser. You can use the adduser variables to create the appropriate paths in your main /etc/passwd file, or simply add the user and edit the /etc/passwd file manually. Any user placed in the jail should have their home directory listed as the chroot jail (/home/jail in our earlier example) and should specify the shell as /usr/local/bin/jail. The entry in the /etc/passwd file for a chroot-ed user should look something like this:

    username:x:101:101:Jail User:/home/jail:/usr/local/bin/jail

    Once you've specified the user to be jailed in your main /etc/passwd file, you can must then add him in chroot-ed environment. The Jail Chroot utility for doing this is called addjailuser and it has a very simple syntax. You must specify 4 variables when adding a user with addjailuser in the format:

    addjailuser chrootdir userdir usershell username

    The "chrootdir" variable is the path to the jail you've created. In our example, that would be /home/jail. (As you can see, this makes creating users in multiple chroot-ed environments very easy.) The "userdir" variable specifies the directory in the jail that will be the home directory for the user. To keep users consistent, we recommend creating a home directory for chroot-ed users just as you would for normal users. The only difference is that normal accounts will exist in the absolute path /home, and chroot-ed users will exist in the absolute path /home/jail/home, but will see essentially the same paths as normal users. The "usershell" variable points to the shell path inside the jail, so /bin/bash will be the norm, unless you install other shells in the environment. The "username" variable should be self-explanatory. Using these variables, you could add the username "fred" to our example jail in /home/jail with the command

    addjailuser /home/jail /home/fred /bin/bash fred

    This will create the necessary entries in the chroot-ed passwd file as well as create the directories for the user (/home/jail/home/fred) as well.

    Simplicity and Security

    Creating chroot jail environments used to be one of those dreaded tasks for system administrators. It was time consuming. It was tedious. And if you did something wrong, it was back to square one. The Jail Chroot Project streamlines these tasks and provides very easy to use tools for getting the job done. If you want to secure your remote access accounts with a chroot-ed environment on GNU/Linux (or any *NIX system for that matter), you need to get a copy of Jail Chroot Project tarball and get cracking. You'll be glad you did.

    Chroot Jail Project Home Page

    Slashdot Chroot Jails Made Easy

    Re:what do I do with it? (Score:5, Informative)
    by phaze3000 on Saturday October 12, @04:39AM (#4436328)
    (User #204500 Info |

    The chroot jail approach is pretty cool, and gives a great layer of security for the system too. In the long run, though, I hope the standard aproach becomes User Mode Linux.

    I don't. A UML installation normally has far more in the way of tools than a chroot-jail. if a cracker exploits a vulnerable daemon and gets into UML they have far more opportunity to do badness. If, on the other hand, they exploit a vulnerable chroot-jailed daemon then if it's well set up all they'll have access to is probably /dev/urandom and /dev/log - neither of which they can do any great damage with. UML is a great tool, but this really isn't the best way to use it.

    jail != chroot (Score:5, Informative)
    by zdzichu (zdzichu@ir c . pl) on Saturday October 12, @04:25AM (#4436314)
    (User #100333 Info | | Last Journal: Sunday October 06, @11:49AM)
    Jail is a term taken from BSD.
    In BSD, jail and chroot are two different things, althrough very similar. There exist two syscalls - jail() and chroot().

    What's the difference?
    Chroot is ordinary chroot, the same as in linux. You do chroot /something bin, and /something becomes root direcorty (/) of run program. This program can't open for example /etc/passwd, because _real_ /etc doesn't exist in it's /. Chrooted program's /etc is in fact /something/etc.
    But if you goot root priviledges you can easily break chroot. Just make a special file named 'hda1' beeing a device node (like those in /dev) inside chroot, mount it, and ... voila! You have access to whole disk. Chroot is broken. Of course, you must have access for making file, but must chroot have.

    Jail is slightly different. It not only hold process in some directory. It's also *restrict* certain *syscalls*. So you can't mount anything, change network settings and some more. Jail is more restrictive and probably you can't break it even if you have root access in jail.

    Jail, because of blocking syscalls, must have some help from kernel. Right now, there is a jail() in FreeBSD and probably NetBSD. OpenBSD don't have it - Theo says it's too complicated to be secure. Also Linux don't have jail().

    If you want more information, browse FreeBSD man pages, avaiable online.

    Just one problem... (Score:5, Informative)
    by The Fanta Menace on Saturday October 12, @04:29AM (#4436319)
    (User #607612 Info |
    Although they are a step towards higher security, chroot jails are not infallible.

    If there's a security hole in an application, it's still possible for an attacker to get root (but yes, they'll be confined to the chroot environment).

    But then, under Linux, at least, the attacked will still be able to mount /proc, if they find a way of getting binaries into the machine, which will enable a number of possible attacks on the machine, by altering stuff under /proc/sys.

    It may also be possible for the attacker to create device files (eg, /dev/hda) and write directly to the disk.

    So, all in all, even if you're running in a chroot jail, it helps to make sure your apps are running as non-root, if you can. authbind [] is your friend.

    Feature Request: RPM Integration (Score:4, Interesting)
    by mbogosian ([email protected]) on Saturday October 12, @04:26AM (#4436315)
    (User #537034 Info)
    The chroot jail looks like a tinkerer's paradise. My only question is how is software installation done for non trivial programs?

    From the site:

    Now, we are going to install the 'awk' program into the chrooted environment. We need to call the addjailsw script with the -P argument:

    /usr/local/bin/addjailsw /var/chroot -P awk

    The output for the script will be something like this:

    A component of Jail
    Juan M. Casillas

    Guessing awk args(0)
    creating /var/chroot//lib/
    Warning: file /var/chroot/lib/ exists. \
    Overwritting it
    creating /var/chroot//usr/bin/awk
    creating /var/chroot//etc/
    Warning: file /var/chroot/etc/ exists. \
    Overwritting it
    creating /var/chroot//lib/
    creating /var/chroot//lib/
    Warning: file /var/chroot/lib/ exists. \
    Overwritting it


    Again, not to minimize the outstanding work here, but what if I want to create chroot jails for the LAMP class I'm teaching (I'm not really, but this seems like a cool application) so they can all have their own Apache installations? It sounds like chroot will know to move the httpd binary and the required shared libraries, but what about the rest of the admin shell scripts, server root, shared icons dir, mime types file, etc.?

    Then what happens if I want to upgrade? My guess is a fair amount of bootstrapping needs to be done in the new root....

    What might be really cool is for addjailsw to be RPM-aware so I could do a addjailsw mod_ssl-2.8.7-6 which would get a list of necessary files and package dependencies and install them in the new root and update the RPM DB in the new root as well.

    Maybe just wishful thinking....

    SecurityFocus/Configuring IPsec-IKE on Solaris Ido Dubrawsky, securityFocus

    RATS 2.0 released

    RATS, the Rough Auditing Tool for Security, is a security auditing utility for C, C++, Python, Perl and PHP code. RATS scans source code, finding potentially dangerous function calls. The goal of this project is not to definitively find bugs. The current goal is to provide a reasonable starting point for performing manual security audits. RATS is released under version 2 of the GNU Public License (GPL).

    Sudo Aliases and Exclusions

    In his previous article, OnLamp's Michael Lucas looked at the basic sudo(8) setup. The hardest part of using sudo is configuring its permissions file, sudoers. As you can imagine, once you have several different machines with multiple administrators all with different levels of privilege, sudoers quickly gets very complicated. Aliases can simplify sudo maintenance and greatly clean up your sudo configuration.

    Linux Journal On-Line

    Stealthful Logging

    Now it's time to combine the previous two techniques in a third one: stealth logging. Normally, a central log server runs syslog or syslog-ng. And indeed, it's possible to capture log packets via a non-IP-addressed interface with Snort and pass them to syslog or syslog-ng. However, it's a lot simpler to let Snort write the packets to a log file itself. The method I'm about to describe uses Snort, tail and awk instead of a traditional logger (on the central logserver, that is; on hosts that send logs you'll still need to configure syslog or syslog-ng as described below).

    Suppose you have a LAN segment with several servers whose log messages you'd like sent to a single log server. Suppose further that you're far less concerned with the confidentiality of these log messages than with their integrity. You don't care if anybody eavesdrops the messages, but you don't want the messages tampered with once they've been received by the central log server. Your log server, therefore, is connected to the LAN via a non-IP-addressed interface and will sniff log packets sent to a bogus IP address on the LAN.

    Configuring Your Hosts to Send Logs to the Stealth Logger

    On each server from which you wish to send logs, you'll need to do two things. The first step is to configure each sender's system logger to send its messages to the bogus IP. By ``bogus'', I only mean that no host actually has that IP address; it must be valid for the LAN in question. Suppose our example LAN's network address is and our bogus logger-host address is Servers on the LAN that use standard syslog will each need a line like this in /etc/syslog.conf:

    *.info @

    On servers that use syslog-ng, you'll need several lines in /etc/syslog-ng/syslog-ng.conf, like these:

    destination d_loghost { udp(ip(
    port(514)); };
    filter f_info { level(info); };
    log { filter(f_info); destination(d_loghost); };

    In either case you may wish to specify different criteria from simply saying ``all messages whose severity is 'info' or higher'', as shown in the above two examples.

    Besides the appropriate lines in its logger's configuration file, each log sender will also need a static ARP entry for the bogus IP address. If your LAN consists of a hub or a series of ``cascaded'' hubs, this ARP address also can be bogus. If your LAN is switched, you'll instead need to specify the real MAC address (hardware address) of the log server. The command to add a static ARP entry on our example log-sending servers is:

    arp -s 00:04:C2:56:54:58

    where is our bogus log-host IP, and 00:04:C2:56:54:58 is either a bogus MAC address or the real MAC address of our stealth logger's non-IP-addressed interface.

    Now each server on our protected LAN is configured to send its logs to, and in the case of a switched LAN, they'll be sent to the stealth logger's switch port. Now all we need to do is configure the stealth logger itself

    Message 9 in thread

    From: Casper H.S. Dik ([email protected])
    Subject: Re: su - access

    View this article only

    Date: 2002-08-28 08:00:22 PST

    "Sree" <[email protected]> writes:
    >Dear Friends,
    >how to provide su access to oracle user and disable direct logging throught
    >ssh or telnet. only for user oracle.On Sun systems.
    On Solaris systems with RBAC (s8+, I think) you can make the oracle
    user into a "role"; that disables direct login access to the account
    and also allows you to specify which users can su to it.
    see user_attr(4) and rbac(5).
    From: Jay G. Scott ([email protected])
    Subject: PAM expertise sought
    View this article only

    Date: 2002-09-04 12:25:05 PST

    I've been looking at PAM, and it's a handful, IMHO.
    Here's what I'm after; the question is, is there something
    I can cannibalize to do this?
    When a user logs in, I want to prompt them for the group
    they intend to use.  I can do all the logic of checking
    to see they're in the group and so forth, what I can't figure
    out is how to go about giving the prompt and getting the
    Do I want to add to the stack in pam.conf?  That is, do I
    want to simply add a line in a configuration file and
    (I assume) supply the module to process that line?
    That seems like the thing I'd most like to do.  I want
    to be able to run this on Solaris if necessary.  If I
    can write a module to process a line in pam.conf, then
    it's trivial to add in the module and edit pam.conf, and
    viola, I've got my extra requirement on any and all
    machines I want.
    I tried looking in several modules which I thought
    would do something similar, but i just don't see
    where the prompt is being sent, or the reply gotten.
    Can you tell me where to look in an existing module
    so I can see how it's done?
    Or maybe I have the wrong idea altogether about PAM?
    Jay Scott		512-835-3553		[email protected]
    Head of Sun Support, Sr. Operating Systems Specialist
    Applied Research Labs, Computer Science Div.                   S224
    University of Texas at Austin

    Post a follow-up to this message

    Message 2 in thread

    From: Jay G. Scott ([email protected])
    Subject: Re: PAM expertise sought

    View this article only

    Date: 2002-09-06 13:15:04 PST

    In article <[email protected]>,
    Jay G. Scott <[email protected]> wrote:
    >When a user logs in, I want to prompt them for the group
    >they intend to use.  I can do all the logic of checking
    >to see they're in the group and so forth, what I can't figure
    >out is how to go about giving the prompt and getting the
    a tip from Bruce Hudson (thx) got me started.
    what i found out was that, while you can call setgid() from
    lots of places, the only one which i found would remember
    that setgid() had been called was in the pam_sm_setcred()
    routine.  however, i couldn't get pam_setcred() to do the
    prompting like i thought it should.  pam_sm_authenticate()
    would prompt, but setgid() wouldn't be remembered.
    i also didn't know that the way to get values passed from
    one routine to another was via pam_set_data(),
    pam_get_data().  now it's easy:  authenticate prompts
    and calls pam_set_data(), setcred calls pam_get_data()
    and calls setgid().
    that, plus some relatively easy mods to pam.conf, and
    i'm almost in business.
    i notice that CDE's window for getting the group (my
    addition, that is) contains the username, as though
    that was the default group.  seems like that ought
    to be a matter of zeroing the response msg before
    calling the prompt, but to me, it looks like it is
    zeroed.  perhaps i can simply supply new structs or
    Jay Scott		512-835-3553		[email protected]
    Head of Sun Support, Sr. Operating Systems Specialist
    Applied Research Labs, Computer Science Div.                   S224
    University of Texas at Austin Free tools; two of note

    RC22534 "Thirty Years Later: Lessons from the Multics Security Evaluation." This is a fresh look, after 30 years, by the guys who did the seminal security analysis on Multics.

    GeodSoft How-To Hardening Systems, Users, Groups and Security -- George Shaffer page. He understand this littly understood area of Unix security better than most.

    PatchPro Select here to download Patch Manager Base 1.0.

    This application allows you to analyze your system, download required patches and install them. It also resolves patch dependencies when you install individual patches. Patch Manager Base 1.0 uses PatchPro to analyze, download and install patches. It has the same security features as PatchPro for Solaris 9.

    Alexander Geschonneck's security page This is a purely link page that contains some interesting links.

    Solaris 9 Operating Environment Data Sheet -- Security in the Solaris 9 Operating Environment. It took Sun only ten years to integrate TCP-wrappers into the system ;-) Still if they managed to postponed this till 2002 it's unclear why not xinetd :-) Among other things:

    Solaris Secure Shell -- Now integrated into the Solaris 9 Operating Environment, Solaris Secure Shell enables secure and easy-to-use network administration. Based on the established OpenSSH...

    System Minimization -- The new system packaging architecture of the Solaris 9 Operating Environment enables organizations to custom build a Solaris 9 system based on a higher granularity of available install packages. In short, fewer unnecessary packages installed on a system means fewer opportunities for system attack.

    For example, Telnet is a standalone package as opposed to being a part of the core package. This allows for a system configuration where only service-specific features and systems applications are installed, and mitigates the risk of introducing a potential security hole.

    Configuring TCP-IP

    In case the install program doesn''t let you configure the network properly, you can do it by hand afterwards.

    Configuring DNS


    Running BIND v8 chrooted on Solaris 5-6-7

    FOCUS on Sun Solaris Default Processes and init.d Pt. I

    This article has been written to provide insight into a stock installation of Solaris 8, and the services started by default. Solaris 8 by default runs many services. This example was provided using Solaris 8, which is the latest version available, and a Sparcstation 20. Most of this document will apply to releases of Solaris prior to 8, and to both the Sparc and Intel architectures. For documentation purposes, a full OEM install was done. Many topics discussed will be familiar to seasoned administrators. However, this document will benefit all parties involved in the administration and security aspects of Solaris.

    FOCUS on Sun Solaris and inetd.conf Part 1

    This collection of material has been written to further clarify one of the more mystical configuration files on today's Solaris Operating System. For this example, we make use of the latest distribution of Solaris (at this time, 7). The topics covered are quite familiar to most seasoned administrators, although this publication has been written with administrators from beginning to advanced skill levels in mind.

    ***+ SAGE ;login - Auditing - The Ugly Duckling of Computers -- old but useful paper [ Jul 10, 2000]

    Setting Up Auditing: The Specifics for Solaris 2.X

    The auditing package that comes with Solaris is part of the BSM (Basic Security Module) package. The audit daemon auditd is the process that performs the auditing on Solaris systems. It is started by default if the /etc/security/audit_startup file exists. The actions that can be audited are defined in the /etc/security/audit_event file. This file can be customized, but it is very in-depth and beyond the scope of this article (the answerbook has a very good description of the whole process and files involved).

    Audit flags indicate which classes of events to audit. Systemwide defaults are listed in /etc/security/audit_control. This file is very important and is the basis for the rest of the discussion. This file is similar to the "User Manager->Polices->Audit" setup in NT; it controls will be audited on the system and what will not. Set up improperly, and you will either have too much information or too little. A man on audit_classes(4) will give you a large amount of information. In standing with my initial recommendations, here is an audit_control file to start with:


    Let's see what this means. The first line defines the directory for the audit files to be placed. This location must have adequate space; if it fills up it will lock you out.[1] You can have more than one dirflag in the file, and they will be used in the order specified. The second line is for events attributable to a user, and tells us the following: (see the audit_event file for list of actions that fall into a class):

    lo ≠ all login and logout events
    ad ≠ all administrative actions
    -fm ≠ all failed change of object attributes (chmod, flock, etc.)
    -fc ≠ all failed creation of objects
    -nt ≠ all failed Network events (This may be noisy)

    The third line is for events that are not attributable to a specific user. The fourth line tells us the minimum free in the dir files before we get a warning message from the audit system. The audit -s command will cause the auditd to reread this file after editing.

    The other file of interest is the /etc/security/audit_user. This file allows more specific auditing of individual users. If specified, the flags in this file are combined with the global flags in audit_control to provide a more granular auditing ability.

    Keeping Solaris Audit Files Manageable

    To keep audit file manageable, a cron job can be set up to periodically rotate the audit files. The audit -n command will checkpoint the logs. This process closes the current audit log and opens another. Then you can process the just closed audit file. Figure 1 is a rudimentary script that will process the just closed audit log. Figure 2 is a script to store and rotate audit logs created during the auditreduce portion, a simple modification of the newsyslog script.

    Audit maintenance on Solaris has a steep learning curve, but it flattens out pretty quickly. The best documentation is in the answerbook. It is specific and very descriptive. I recommend that anyone not strongly familiar with Solaris auditing read it before you implement the system.


    Now that my primary job is helping those unfortunate individuals or sites with security incidents, I see the errors in not taking the time in 1991 to "finish the job." In an incident, if you don't have good logs (i.e., auditing), you'd better have good luck. The chances of figuring out what happened without good auditing are few and far between. If you take one thing from this article, make it this: Take the time, learn your systems, and set up auditing that is adequateand appropriate for your systems.

    In the next issue, I will discuss central management of UNIX and NT audit files.

    Sun BluePrints OnLine - Articles January 2000 SolarisTM Operating Environment Security -- PDF document. By Alex Noordergraaf and Keith Watson [Jan 2000].

    The Solaris Operating Environment is a flexible, general purpose operating system. Due to its general nature, changes must be made to secure the system against unauthorized access and modification. This article discusses the Solaris Operating Environment subsystems and the security issues surrounding those subsystems. Recommendations are made on the manner in which those subsystems should be secured.

    As with any security decisions, a balance must exist between system manageability and security. Some changes in this article will not be applicable to all environments. The removal of some of the Solaris Operating Environment services mentioned in this article may negatively impact the ability to effectively maintain a system. You must know your system and security requirements before starting.

    This article splits the discussion of the Solaris Operating Environment system security into two parts. The first section deals with file system and local security. The second half of this article deals with the security of network services.

    The information in this article applies to the Solaris 2.5.1, 2.6, and 7 Operating Environment. Some system changes described in this article have been integrated into Solaris 8 Operating Environment. Where appropriate, these new changes are mentioned. Older versions of the Solaris Operating Environment may be configured in similar ways. Some investigation is necessary before making the changes suggested in this article to these older versions.

    ***** SolarisTM Operating Environment Minimization for Security- A Simple, Reproducible and Secure Application Installation Methodology

    ***** SolarisTM Operating Environment Network Settings for Security
    -by Keith Watson and Alex Noordergraaf
    Discuss the many low-level network options available within Solaris and their impact on security.




    Groupthink : Two Party System as Polyarchy : Corruption of Regulators : Bureaucracies : Understanding Micromanagers and Control Freaks : Toxic Managers :   Harvard Mafia : Diplomatic Communication : Surviving a Bad Performance Review : Insufficient Retirement Funds as Immanent Problem of Neoliberal Regime : PseudoScience : Who Rules America : Neoliberalism  : The Iron Law of Oligarchy : Libertarian Philosophy


    War and Peace : Skeptical Finance : John Kenneth Galbraith :Talleyrand : Oscar Wilde : Otto Von Bismarck : Keynes : George Carlin : Skeptics : Propaganda  : SE quotes : Language Design and Programming Quotes : Random IT-related quotesSomerset Maugham : Marcus Aurelius : Kurt Vonnegut : Eric Hoffer : Winston Churchill : Napoleon Bonaparte : Ambrose BierceBernard Shaw : Mark Twain Quotes


    Vol 25, No.12 (December, 2013) Rational Fools vs. Efficient Crooks The efficient markets hypothesis : Political Skeptic Bulletin, 2013 : Unemployment Bulletin, 2010 :  Vol 23, No.10 (October, 2011) An observation about corporate security departments : Slightly Skeptical Euromaydan Chronicles, June 2014 : Greenspan legacy bulletin, 2008 : Vol 25, No.10 (October, 2013) Cryptolocker Trojan (Win32/Crilock.A) : Vol 25, No.08 (August, 2013) Cloud providers as intelligence collection hubs : Financial Humor Bulletin, 2010 : Inequality Bulletin, 2009 : Financial Humor Bulletin, 2008 : Copyleft Problems Bulletin, 2004 : Financial Humor Bulletin, 2011 : Energy Bulletin, 2010 : Malware Protection Bulletin, 2010 : Vol 26, No.1 (January, 2013) Object-Oriented Cult : Political Skeptic Bulletin, 2011 : Vol 23, No.11 (November, 2011) Softpanorama classification of sysadmin horror stories : Vol 25, No.05 (May, 2013) Corporate bullshit as a communication method  : Vol 25, No.06 (June, 2013) A Note on the Relationship of Brooks Law and Conway Law


    Fifty glorious years (1950-2000): the triumph of the US computer engineering : Donald Knuth : TAoCP and its Influence of Computer Science : Richard Stallman : Linus Torvalds  : Larry Wall  : John K. Ousterhout : CTSS : Multix OS Unix History : Unix shell history : VI editor : History of pipes concept : Solaris : MS DOSProgramming Languages History : PL/1 : Simula 67 : C : History of GCC developmentScripting Languages : Perl history   : OS History : Mail : DNS : SSH : CPU Instruction Sets : SPARC systems 1987-2006 : Norton Commander : Norton Utilities : Norton Ghost : Frontpage history : Malware Defense History : GNU Screen : OSS early history

    Classic books:

    The Peter Principle : Parkinson Law : 1984 : The Mythical Man-MonthHow to Solve It by George Polya : The Art of Computer Programming : The Elements of Programming Style : The Unix Haterís Handbook : The Jargon file : The True Believer : Programming Pearls : The Good Soldier Svejk : The Power Elite

    Most popular humor pages:

    Manifest of the Softpanorama IT Slacker Society : Ten Commandments of the IT Slackers Society : Computer Humor Collection : BSD Logo Story : The Cuckoo's Egg : IT Slang : C++ Humor : ARE YOU A BBS ADDICT? : The Perl Purity Test : Object oriented programmers of all nations : Financial Humor : Financial Humor Bulletin, 2008 : Financial Humor Bulletin, 2010 : The Most Comprehensive Collection of Editor-related Humor : Programming Language Humor : Goldman Sachs related humor : Greenspan humor : C Humor : Scripting Humor : Real Programmers Humor : Web Humor : GPL-related Humor : OFM Humor : Politically Incorrect Humor : IDS Humor : "Linux Sucks" Humor : Russian Musical Humor : Best Russian Programmer Humor : Microsoft plans to buy Catholic Church : Richard Stallman Related Humor : Admin Humor : Perl-related Humor : Linus Torvalds Related humor : PseudoScience Related Humor : Networking Humor : Shell Humor : Financial Humor Bulletin, 2011 : Financial Humor Bulletin, 2012 : Financial Humor Bulletin, 2013 : Java Humor : Software Engineering Humor : Sun Solaris Related Humor : Education Humor : IBM Humor : Assembler-related Humor : VIM Humor : Computer Viruses Humor : Bright tomorrow is rescheduled to a day after tomorrow : Classic Computer Humor

    The Last but not Least Technology is dominated by two types of people: those who understand what they do not manage and those who manage what they do not understand ~Archibald Putt. Ph.D

    Copyright © 1996-2021 by Softpanorama Society. was initially created as a service to the (now defunct) UN Sustainable Development Networking Programme (SDNP) without any remuneration. This document is an industrial compilation designed and created exclusively for educational use and is distributed under the Softpanorama Content License. Original materials copyright belong to respective owners. Quotes are made for educational purposes only in compliance with the fair use doctrine.

    FAIR USE NOTICE This site contains copyrighted material the use of which has not always been specifically authorized by the copyright owner. We are making such material available to advance understanding of computer science, IT technology, economic, scientific, and social issues. We believe this constitutes a 'fair use' of any such copyrighted material as provided by section 107 of the US Copyright Law according to which such material can be distributed without profit exclusively for research and educational purposes.

    This is a Spartan WHYFF (We Help You For Free) site written by people for whom English is not a native language. Grammar and spelling errors should be expected. The site contain some broken links as it develops like a living tree...

    You can use PayPal to to buy a cup of coffee for authors of this site


    The statements, views and opinions presented on this web page are those of the author (or referenced source) and are not endorsed by, nor do they necessarily reflect, the opinions of the Softpanorama society. We do not warrant the correctness of the information provided or its fitness for any purpose. The site uses AdSense so you need to be aware of Google privacy policy. You you do not want to be tracked by Google please disable Javascript for this site. This site is perfectly usable without Javascript.

    Last modified: March 12, 2019