RE: Prevent remote User login

From: Wheeler, Randy (rwheeler_at_devry.com)
Date: 10/16/03

  • Next message: Lisa Bogar: "Solaris 9 ssh"
    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
    

  • Next message: Lisa Bogar: "Solaris 9 ssh"