RE: Prevent remote User login

• Previous message: Blair Barrett: "Re: Prevent remote User login"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]

To: "'Glenn M. Brunette, Jr.'" <glenn.brunette@sun.com>, Noel del Rosario <noeldelrosario@yahoo.com>
Date: Thu, 16 Oct 2003 14:50:29 -0500

Noel,

also take a look at the included stripped down version for getting RBAC to
work, even though the blueprints are an excellent resource it can be
confusing until you actually set up a role

Operating System: Solaris 8
UNIX has always allowed users to be granted access privileges for running
programs that they normally don't have access to. Even with modern-day
Solaris, you still have the ability to set your user id and group id, as
well as access control lists, and you can still use the venerable
third-party sudo program.

Things have changed just a tad with Solaris 8, though. We now have a process
known as Role-based Access Control (RBAC). Although sudo is a bit easier to
set up, with RBAC you no longer need to compile another program to provide
this functionality.

Foundation
There are essentially two directories and four files that are used to
configure RBAC. The file in the /etc directory is user_attr. The files in
the /etc/security directory are auth_attr, prof_attr and exec_attr.
The /etc/user_attr file is an extension to /etc/passwd and /etc/shadow. When
you create a role, it's stored in this file.

A role is similar to a typical user account, except you can't log on to the
system with a role user account. You log on as a normal user and then su to
the role. The role determines which commands your users have access to
outside of the normal user commands.

The /etc/security/auth_attr file is used to grant access to normal
system-type commands, such as changing the date and time or Printer
Management. When defining a custom role, you may or may not need to update
this file.

The /etc/security/prof_attr file contains execution profiles. A tag in this
file matches tags in the exec_attr file.

The /etc/security/exec_attr file is where the actual commands that the user
can run are stored. This is the key to the whole system.

All of these files use the following delimiters:

Colon. Used as a field separator within the file. For example, you could
have a line that looks as follows:
Fruit: Vegetables: Meats: Breads

Semicolon. Used to separate key value pairs within the file. We could
separate apples and lemons like so:
apples=red; lemons=yellow

Comma. Used to separate an ordered list within the file:
lions, tigers, bears

Period. Used to separate the prefix from the suffix. This separation defines
execution profiles with finer granularity:
        solaris.system.date
        solaris.system.shutdown

To create a role-based access control, you add the role to user_attr and
then create the entries in prof_attr and exec_attr. You can use the built-in
authority schemes as defined in the auth_attr file, or you can add your own
to this file as well.

The four files
It's important to understand these files and how they relate to each other.
To help you understand them, we'll now describe the use of each file in
detail.
/etc/user_attr
The first file we'll examine is /etc/user_attr. The Extender User Attributes
(/etc/user_attr) file is an extension to your normal /etc/passwd and
/etc/shadow files. This file allows you to assign roles to users, specify
which account you'll use to run certain commands, and assign users to
profiles and authorizations.
The role account also has special shells associated with it. Instead of
assigning the typical shells such as bourne, csh, ksh, etc., you select one
of the three profile shells:

pfsh. Profile bourne shell.
pfcsh. Profile C shell.
pfksh. Profile Korn shell.
If the user decides to change the shell to any shell other than these, then
the role commands will not work. You must be in one of these special shells
to execute the role commands.

The /etc/user_attr file has the following fields:

User. The name of the user or role as it appears in /etc/passwd.
Qualifier. Reserved for future use.
Res1. Reserved for future use.
Res2. Reserved for future use.
Attr. An optional list that describes the security attributes to be applied
when the user runs the commands. There are four valid keys:

Auths. Specifies a name chosen from the names defined in
/etc/security/auth_attr. These names can contain wildcards.
Profiles. Specifies a name chosen from the profile names specified in
/etc/security/prof_attr. A profile determines which commands a user can
execute. There are some severe security implications for Profiles that we'll
discuss later.
Roles. Defines each role needed. They are defined in this same file. Roles
are defined by setting the type to role. You can't assign roles to other
roles.
Type. Indicates what kind of account it is. Type can be set to "normal,"
which indicates that it's a normal user, or to "role" if the account is for
a role.
These are all of the possible elements the user_attr file can contain. The
following is an example:

root::::type=normal;auths=solaris.*, \
solaris.grant;profiles=All

The first field specifies root. We know that it's a user account, as the
type is set to "normal." The root user account is authorized to use the
solaris.* and solaris.grant authorizations as defined in auth_attr, and can
utilize commands that are defined for the "All" profile.

An example of a role entry would look like this:

filemngr::::type=role;profile=Filesystem
?Management,All

The name of the role is filemngr, as indicated by the type=role tag, and the
role has access to the commands that are allowed by the "Filesystem
Management" profile and the "All" profiles.
/etc/security/auth_attr
The second file we'll look at is /etc/security/aut_attr. This file contains
authorizations to restricted system functions. Some of these functions
include changing date/time, system shutdown, auditing, and other system-type
functions. You can create your own system definitions and include them in
this file as well. Any function that starts with "solaris.something" is
defined by Sun. If you want to add your own authorizations, we recommend
that you use your company Web address in reverse format (i.e.,
com.yourcompany.authorization_name). By doing this, you'll ensure that
future upgrades or changes in future versions of Solaris won't wipe out your
custom definitions.
You can add authorizations for users or roles in one of two ways. You can
either add authorizations directly in the /etc/user_attr file, or indirectly
by adding them to profiles and then assigning the profile to a user or role.

Certain privileged programs use this file to determine the users' rights to
execute that program. This file also defines the location of the Help file
to use in GUI programs. The file has the following fields:

Authname. A unique string used to define the authorization in the format of
prefix.suffix. The prefix should be your company's domain name in reverse
syntax, and the suffix should be the functional area that you're granting
authorizations for. This might look like com.yourcompanyname.authname. If
the authname ends in a period, then it doesn't grant or deny access to
programs, but can be used within a GUI application as a heading.
Res1. Reserved for future use.
Res2. Reserved for future use.
Short-desc. A short description suitable for displaying in a GUI.
Long-desc. A long description that could be used in a GUI Help file.
Attr. An optional list that describes the attributes of the authorization.
The Help keyword identifies a Help file in HTML format. You can access help
files from the index.html file in the /usr/lib/help/auths/locale/C
directory.
Some example entries in this file would look like:

solaris.jobs.:::Cron and At Jobs::
?help=JobHeader.html
solaris.jobs.admin:::Cron & At
?Adminis-trator::help=JobsAdmin.html
solaris.jobs.grant:::Delegate Cron &
?At Administration::help=JobsGrant.html

The first entry ends in a period, so its use is limited to a heading in a
GUI application. The second entry allows a user to view or change cron or at
jobs on the local machine. The third entry is also a special type. Whenever
an authorization ends in .grant, it allows the user to grant authorizations
to other uses. Be careful of using .grant, as whichever user you give this
right to could arbitrarily let other users use these commands as well.

/etc/security/prof_attr
An execution profile is a way of bundling together all the authorizations
and commands that you then assign to users and roles.
The file has the following fields:

Profname. The case-sensitive name of the profile.
Res1. Reserved for future use.
Res2. Reserved for future use.
Desc. This field should explain why the role exists and why you would let a
user run these commands. It should be suitable for use as a Help file for a
GUI application.
Attr. An optional list that describes the authorizations or Help files to be
used by the command upon execution. The Help file has the same
specifications as described for the auth_attr file. The auths keyword
corresponds to authorizations created in the auth_attr file. You can specify
wildcards here.
A couple of example entries from this file include the following:

Audit Control:::Administer the audit
?subsystem:auths=solaris.audit.config,
?solaris.jobs.admin;help=AuditControl.html

Device Management:::Control Access to
?Remov-able Me-dia:auths=solaris.device.*;
?help=DevMgmt.html

The first example shows that the profile name is "Audit Control." This
profile is authorized to run all commands associated with
solaris.audit.config in the auth_attr file. The Help file is
/usr/lib/help/auths/locale/C/AuditControl.html. The second example shows the
use of a wildcard allowing the user to run all commands associated with the
solaris.device authorizations as defined in auth_attr.

/etc/security/exec_attr
This file is the key to the whole system. In it, we define exactly which
commands the user can run. After you define a policy, you need to edit this
file and define which commands that profile is allowed to run, as well as
how you want that command to run. In /etc/security/exec_attr, you can tell
the system to run the command as user id, effective user id, group id, or
effective group id. The file has the following fields:
Name. The name of the profile. This matches the entry in prof_attr.
Policy. The security policy associated with the execution profile. Currently
there's only one: suser.
Type. Currently the only valid type is cmd (command).
Res1. Reserved for future use.
Res2. Reserved for future use.
Id. The full path to and the name of the command that the user is allowed to
run. You can use wildcards here. If you need to use command line switches,
then you'll need to write a script and point the id to the full path name of
the script.
Attr. An optional list containing one or more of the following followed by a
value: uid, euid, gid or guid. The value or name of the user id, effective
user id, group id, or effective user id is the same as defined in
/etc/passwd or /etc/group.
A few example entries from this file include:

All:suser:cmd:::*:
Audit Control:suser:cmd:::
?/etc/init.d/audit:euid=0;egid=3
Audit Control:suser:cmd:::
?/etc/security/bsmconv:uid=0
Audit Control:suser:cmd:::
?/etc/security/bsmunconv:uid=0
Audit Control:suser:cmd:::
?/usr/sbin/audit:euid=0

The first entry here is of some importance. The "All" profile lets the user
run any command on the system without any special privileges. Not granting a
user access to the "All" profile takes away this access. The only commands
that the user can now run are those that the remaining profiles grant him
access to run. By not granting access to the "All" profile, you can severely
restrict the commands that the user is allowed to run, even down to just one
command.

The rest of the examples show you that the profile "Audit Control" can be
set up to run a few different commands in different directories. Also, you
can see that some of these commands run as uid=0 or euid=0, and the first
command will also run with an egid equal to 3. Make sure that these match up
with the permissions of the command on the file system.

Logins and su
In order for the typical user to use these commands, he must log on as
himself and then su to the role account. No one is allowed to log on with a
role account. A role is created in the same fashion as a user. It has all
the attributes that a normal user account has. If you decide that you want
to temporarily suspend a role, simply change the password on the role
account and don't give anyone the new password. When you're ready to resume
the role, either reset the password to what it was or assign a new one and
let the users know what it is.
Role commands
The following commands are used to create and manage roles: roleadd,
rolemod, roledel, /etc/init.d/nscd, profiles, roles, useradd, userdel,
usermod and vi. Note that admintool isn't listed.
To create a role, use the following roleadd command:

roleadd -c comment -d home dir -e
?expire -f inactive -g group -G group
?-m -u uid -s shell -A authorization
?-P profile role

Those familiar with useradd will have no problem with this command. The -m
creates the home dir if it doesn't already exist. Make sure that you
remember to use pfsh, pfksh or pfcsh for the shell. Before assigning an
authorization or profile, they must exist in auth_attr or prof_attr,
respectively, before issuing the command. The role account has the same
restrictions as a user account in terms of length and other attributes.

To modify a role, you use the rolemod command. This command is analogous to
the usermod command, and follows the same format:

rolemod -u uid -g group -G group -d
?dir -m -s shell -c comment -l new_name
?-f inactive -e expire -A authorization
?-P profile role

Finally, to remove a role, use the roledel command as follows:

roledel -r role

As with userdel, the -r removes the home directory.

If you want to see a list of profiles that you currently belong to, use the
profiles command:

profiles -l user

Using the -l switch allows you to see which commands are associated with the
profile, as well as the special attributes, such as eid or gid, of the
command. If you want to see the profiles assigned to a particular user, then
specify the user's name as part of the command.

If you want to see what roles are assigned to your user account, you can use
the roles command as follows:

roles user

The useradd and usermod commands have been updated with additional switches.
This includes the -A and -P options, respectively, which assign
authorizations and profiles to the user. They have also added the -R option
to assign roles to a user.

Example
One of the more useful commands for helping to debug network-related
problems is the snoop command. Because this command can be used to read
passwords, normal users usually don't have access to this command. The
following is an example of how to give users access to the snoop command.
Remember that this is just an example, and you probably will not want to do
this in the real world.
Add the following to the end of the /etc/security/exec_attr file:

Snoop:suser:cmd:::/usr/sbin/snoop:uid=0

Now, update the /etc/security/prof_attr file as follows:
Snoop:::Allow users to run the snoop command:

Once this is complete, create the following role:
roleadd -m -d /export/home/snoop -c
?"Allow users to run snoop" -s
?/usr/bin/pfsh -P Snoop,All usrsnoop

Then you can set the password for the usrsnoop account:
passwd usrsnoop

Now, grant the appropriate user accounts the right to use the command:
usermod -R usrsnoop user

You're now ready to test your setup. Do this with the following commands:
su - user
su role (usrsnoop)
run role commands (/usr/sbin/snoop)

Inform the end users of the (role) snoopusr account, the password, and what
it's used for.
Name Server Cache Daemon
Sometimes when you add or modify a role/profile, the role/profile won't take
effect right away. The reason that it may not take effect immediately could
be the name server cache daemon. If you make changes and they aren't showing
up, you may need to stop and then restart this daemon. To do this, issue the
following commands:
/etc/init.d/nscd stop
/etc/init.d/nscd start

You can also try adjusting your nscd settings by modifying /ect/nscd.conf.
Conclusion
Like anything new, getting used to RBAC can take a little time, but in the
long run it will solve problems that are not easily solved by setting UNIX
permissions. It also can augment or replace sudo if you're currently using
that solution.

Noel,

Do you know which version of the Solaris OS that you are using?
If you are using the Solaris OS version 8 or newer, the 'oracle'
or '9ias' accounts may be configured to be roles. By default,
you cannot remotely log into a system as a role - you must log
in as a normal user and then 'su' to a role.

For some introductory information on roles and the Solaris
Role-based Access Control capability see the Sun BluePrints
article titled:

    Role-based Access Control and Secure Shell
    http://www.sun.com/blueprints/0603/817-3062.pdf

You can also find more information on this capability in the
Sun documentation (System Administration Guide: Security
Services: Chapter 17 - Role-based Access Control Overview):

http://docs.sun.com/db/doc/806-4078/6jd6cjs3u?q=Role-based+Access+Control&a=
view

Please let me know if you have any questions.

Glenn

---
Glenn M. Brunette, Jr.
Principal Engineer, Chief Security Architect
Sun Professional Services, United States CTO
Sun Microsystems, Inc.
Noel del Rosario wrote:
>  
> Glenn,
>  
>        Is there something that  could prevent a user to do a remote login
>        to another valid user_id account (say 'oracle' or '9ias' ) but
allows them 
>        to do 'su - oracle' or 'su - 9ias'  after they successfully login
remotelly 
>        using their own user_id account ( say 'rosario' or 'watanabe' ). 
>  
> cheers,
> noel

• Previous message: Blair Barrett: "Re: Prevent remote User login"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]