RBAC

From Genunix

Jump to: navigation, search

Solaris RBAC, or Role Based Access Control, is a practical implementation of the "Least Privilege" model. It provides an alternative to the classic "To Root or Not To Root" problem of either having absolute control or not. The traditional way of coping with this problem is to utilize sudo, which allows you to control under what circumstances a user can act with root authority.

For a more complete listing of security topics, please see Solaris Security Recommendations.

Contents

RBAC vs sudo

An excellent comparison is found here: SUMMARY: sudo vs RBAC.

One thing you can do with sudo that you 'can not do with RBAC is protect functions of a given binary. Example: 

## sudoers config:
benr    ALL=/usr/bin/passwd [A-z]*, !/usr/bin/passwd root

In the above example "benr" is allowed to change passwords but not the root password. This is not possible via RBAC. Please note that one downside to this approach in sudo is that the syntax must match exactly, this is why the first arg is required to avoid the user bypassing this above sudo line with sudo passwd -r files root.

User Accounts

There are 3 unusual properties when using useradd or usermod. They are:

  • -A authorization [, authorization ...]
  • -P profile [, profile ...]
  • -R role [, role ...]

In the above, authorizations come from /etc/security/auth_attr. Authorizations are high level permissions abstractions with fine grained control. You can determine your current level of authorizations using the auths command: 

benr@aeon ~$ auths
solaris.smf.manage,solaris.smf.modify,solaris.device.cdrw,solaris.profmgr.read,solaris.jobs.user,
solaris.mail.mailq,solaris.device.mount.removable,solaris.admin.usermgr.read,solaris.admin.logsvc.read,
solaris.admin.fsmgr.read,solaris.admin.serialmgr.read,solaris.admin.diskmgr.read,
solaris.admin.procmgr.user,solaris.compsys.read,solaris.admin.printer.read,solaris.admin.prodreg.read,
solaris.admin.dcmgr.read,solaris.snmp.read,solaris.project.read,solaris.admin.patchmgr.read,solaris.network.hosts.read,
solaris.admin.volmgr.read

Profiles are defined in /etc/security/prof_attr and are formed from both Solaris Authorizations and exec (sudo style) privs found in /etc/security/exec_attr (in this file each line begins with the Profile name, and includes the command and uid that should be used, normally 0).

We'll discuss roles in the next section.

When using these options to useradd and usermod the settings are placed in /etc/user_attr.

Warning When Modifying Existing Users or Roles

Through my experience editing /etc/user_attr directly has proven problematic, I have no idea why, but it often doesn't work. Thus, you must use usermod. However, be aware that if you, for instance, add a new profile to a user that it will replace your existing profiles with the new ones, not append. Example: 

root@aeon ~$ grep benr /etc/user_attr 
benr::::type=normal;profiles=All;auths=solaris.*,solaris.grant;lock_after_retries=no
root@aeon ~$ usermod -P "Software Installation" benr
UX: usermod: benr is currently logged in, some changes may not take effect until next login.
root@aeon ~$ grep benr /etc/user_attr 
benr::::type=normal;profiles=Software Installation;auths=solaris.*,solaris.grant;lock_after_retries=no

Notice, my existing "All" profile is gone.

Roles

Roles are user accounts that can only be accessed locally (typically by su) by defined users (those associated with the role) that have Profiles or Authorizations associated with them. If this seems redundant to creating a user account and associating Profiles or Auths with it, it is, the difference is that roles can be assumed and then un-assumed, whereas assigning these attributes to a standard user account would have them all the time. In this way you can treat a role like a "water'ed down superuser".

The commands for role management are roleadd, roledel, rolemod, and roles. The latter command is used to report the roles you are currently assuming.

Adding Roles

root@aeon security$ roleadd -P "ZFS File System Management" zfs
root@aeon security$ grep zfs /etc/passwd 
zfs:x:506:1::/home/zfs:/bin/pfsh
root@aeon security$ grep zfs /etc/shadow 
zfs:*LK*:::::::
root@aeon security$ grep zfs /etc/user_attr 
zfs::::type=role;profiles=ZFS File System Management

PLEASE NOTE: Roles are really just user accounts and they must be treated as such. Roles have home directories and passwords. You can not bypass this. Even if you are associated with a role you still need to know that password, have a decent .profile, etc.

Using Roles

Roles, at their core, are just locked user account that can be accessed locally by only certain defined users, those who have that role associated with their account.

The following is an example of associating the "zfs" role with a user account: 

root@aeon security$ usermod -R zfs benr
UX: usermod: benr is currently logged in, some changes may not take effect until next login.

Now to demonstrate using it: 

benr@aeon ~$ roles
zfs
benr@aeon ~$ su zfs
Password: 
$ zfs set quota=150g local/benr
$ exit

This may all seem unneeded, however, what happens when another user who does not have this role associated with his account attemps to do the same thing? 

$ id
uid=507(john) gid=1(other)
$ roles
No roles
$ su zfs
Password: 
Roles can only be assumed by authorized users
su: Sorry

Privilege Sets (psets or ppriv)

Solaris implements an independant authorization mechanism for various Solaris functions and commands known as Privilege Sets ("pset's"). Sometimes these are also called "ppriv's" because of the ppriv command used to modify process privilege sets similar to the way rctladm modifies resource controls of a process.

pset's are used within the RBAC frame by specifying them in /etc/security/exec_attr rather than specifying a uid or euid. Example: 

$ grep privs /etc/security/exec_attr 
Audit Control:solaris:cmd:::/usr/sbin/audit:privs=sys_audit,file_dac_read,proc_owner
Basic Solaris User:solaris:cmd:::/usr/bin/cdda2wav.bin:privs=file_dac_read,sys_devices,proc_priocntl,net_privaddr
...

These associations are then accessed via Profiles.

To determine which privs you require to do some action, try the following method using ppriv debug mode: 

$ zfs snapshot local/benr@adsf
zfs[2701]: missing privilege "sys_mount" (euid = 500, syscall = 54) needed at zfs_secpolicy_write+0x26
cannot create snapshot 'local/benr@adsf': permission denied

$ zpool scrub local
zpool[2702]: missing privilege "sys_config" (euid = 500, syscall = 54) needed at zfs_secpolicy_config+0x1a
cannot scrub local: permission denied

$ reboot
reboot: permission denied

$ ifconfig nge0 down
ifconfig[2704]: missing privilege "sys_ip_config" (euid = 500, syscall = 54) needed at ip_sioctl_copyin_setup+0x100
ifconfig: setifflags: SIOCSLIFFLAGS: nge0: permission denied

$ cat /etc/shadow 
cat[2705]: missing privilege "file_dac_read" (euid = 500, syscall = 225) needed at ufs_iaccess+0xe1
cat: cannot open /etc/shadow

You can list all available privs using the ppriv -l command: 

$ ppriv -l
contract_event
contract_observer
cpc_cpu
dtrace_kernel
...

Profiles

A large number of profiles exist by default, including:

  • ZFS Storage Management: Access to zpool
  • ZFS File System Management: Access to zfs
  • Zone Management: Access to zoneadm, zlogin, and zonecfg
  • File System Management: Access to many FS related tools such as format, mkdir & rmdir (euid 0), mount, umount, fuser, iscsiadm and iscsitadm, and many others.
  • Maintenance and Repair: Ability to start, stop, and analyze corefiles
  • Network Management: Access to ifconfig, snoop, etc (does not include dladm)
  • Process Management: Access to the ptools, kill (euid=0), truss, etc.

Additionally, there are 2 special profiles:

  • All: Lame Duck, see below.
  • Primary Administrator: Given uid=0 and gid=0 to all commands

Example of the power provided by Primary Administrator: 

benr@aeon ~$ cat /etc/shadow
cat: cannot open /etc/shadow: Permission denied
benr@aeon ~$ pfexec cat /etc/shadow
root:rJy8BFH5k4uzQ:13788::::::
daemon:*LK*NP:13792::::::1
bin:*LK*NP:13792::::::1
...

benr@aeon ~$ pfexec format
Searching for disks...done


AVAILABLE DISK SELECTIONS:
       0. c1d0 <DEFAULT cyl 22113 alt 2 hd 255 sec 63>
          /pci@0,0/pci-ide@7/ide@1/cmdk@0,0
...

The All profile is mute, it allows execution of all commands but doesn't convey any permissions or uid, hence it does nothing: 

$ grep All exec_attr 
All:suser:cmd:::*:

The difference is clear when compared against Primary Administrator which allows all commands as uid-0 and gid=0: 

$ grep Primary exec_attr 
Primary Administrator:suser:cmd:::*:uid=0;gid=0

Meta-Profiles

To gain access to specific tools you can find the tool you want in exec_attr and assign the appropriate profile. For instance, you want to use dladm: 

$ grep dladm exec_attr 
Network Link Security:solaris:cmd:::/sbin/dladm:euid=dladm;egid=sys;    privs=sys_net_config,net_rawaccess,proc_audit
Network Management:solaris:cmd:::/sbin/dladm:euid=dladm;egid=sys;       privs=sys_net_config,net_rawaccess,proc_audit

So we can add either of these two profiles, "Network Link Security" or "Network Management", to gain access to the tool.

However, administrators rarely need just a single tool or set of related tools; rather they require several. To this end, within prof_attr a single "meta-profile" can be defined which itself includes several others. Example: 

Operator:::Can perform simple administrative tasks:profiles=Printer Management,Media Backup,All;help=RtOperator.html

There are two important meta-profiles available by default: "Network Management" and "System Administrator". The latter includes all of the following profiles:

  • Audit Review
  • Printer Management
  • Cron Management
  • Device Management
  • File System Management
  • Mail Management
  • Maintenance and Repair
  • Media Backup
  • Media Restore
  • Name Service Management
  • Network Management
  • Object Access Management
  • Process Management
  • Software Installation
  • User Management
  • Project Management

System Administrator vs Primary Administrator Profiles

Its very important to see the difference between these two key profiles. "System Administrator" is a meta-profile and therefore only has access to commands and privs explicitly defined within RBAC's exec_attr; that is to say, it doesn't have untamed, limitless control.

The "Primary Administrator", on the other hand, has limitless control because all commands are executed as uid/gid 0, thus the only difference between Primary Administrator and the "root" user is that the former has to execute all commands through a profile shell (or pfexec).

Authorizations

Solaris Authorizations provide a unique method of providing privileged access which is much more fine grained than other methods. The function of exec_attr is function much like sudo, allowing you to run a given command as someone else, typically root (uid or euid 0). With authorizations you can slice and dice permissions beyond just executing with someone else's privs.

Here is an example of SNMP related authorizations: 

solaris.snmp.:::SNMP Management::help=AuthSnmpHeader.html
solaris.snmp.read:::Get SNMP Information::help=AuthSnmpRead.html
solaris.snmp.write:::Set SNMP Information::help=AuthSnmpWrite.html

Thus, we can assign read (solaris.snmp.read), write (solaris.snmp.write), or read/write (solaris.snmp.*) privileges. This is much more fine grained than executing snmp* as uid 0.

Obviously, authorizations only have meaning to programs that are aware of them, and thus not as commonly utilized as exec profiles.

Authorizations & SMF

The primary consumer of authorizations is SMF, which you'll notice is absent from exec_attr by default. Here is an example of the SMF related auths: 

solaris.smf.:::SMF Management::help=SmfHeader.html
solaris.smf.manage.:::Manage All SMF Service States::help=SmfManageHeader.html
solaris.smf.manage.autofs:::Manage Automount Service States::help=SmfAutofsStates.html
solaris.smf.manage.bind:::Manage DNS Service States::help=BindStates.html
....
solaris.smf.manage.x11:::Manage X11 Service States::
solaris.smf.modify.:::Modify All SMF Service Properties::help=SmfModifyHeader.html
solaris.smf.modify.application:::Modify Application Type Properties::help=SmfModifyAppl.html
solaris.smf.modify.dependency:::Modify Service Dependencies::help=SmfModifyDepend.html
solaris.smf.modify.framework:::Modify Framework Type Properties::help=SmfModifyFramework.html
solaris.smf.modify.iscsitgt:::Add/Remove Values of ISCSI Target Service Properties::help=SmfValueIscsitgt.html
solaris.smf.modify.method:::Modify Service Methods::help=SmfModifyMethod.html
solaris.smf.read.iscsitgt:::Read ISCSI Target secrets::help=SmfValueIscsitgt.html
solaris.smf.value.:::Change Values of SMF Service Properties::help=SmfValueHeader.html
solaris.smf.value.ipsec:::Change Values of SMF IPsec Properties::help=SmfValueIPsec.html
solaris.smf.value.iscsitgt:::Change Values of ISCSI Target Service Properties::help=SmfValueIscsitgt.html
solaris.smf.value.mdns:::Change Values of MDNS Service Properties::help=SmfValueMDNS.html
solaris.smf.value.nwam:::Change Values of SMF Network Auto-Magic Properties::help=SmfValueNWAM.html
solaris.smf.value.postgres:::Change Postgres value properties::
....

The layout is:

  • solaris.smf.: Full SMF control.
    • solaris.smf.manage.: Ability to manage (change state) services (ie: svcadm restart http)
      • solaris.smf.manage.service_name: Ability to manage a specific named service
    • solaris.smf.modify.: Ability to modify (svccfg) all service properties
      • solaris.smf.modify.service_name: Ability to modify a named service
    • solaris.smf.read.: NEW Ability to read protected properties
    • solaris.smf.value.: Ability to change all service properties (but not delete, import, etc)
      • solaris.smf.value.service_name: Ability to change service properties of a named service

The following are example auths and their usage as you'd use them in /etc/user_attr: 

auths=solaris.smf.*        Able to do anything.

auths=solaris.smf.modify   Able to svccfg import/export/delete, etc all services. (but not start/stop!)
auths=solaris.smf.modify.  <-- Does not work.
auths=solaris.smf.modify.* <-- Does not work, even for named services

auths=solaris.smf.manage   <-- Does not work.
auths=solaris.smf.manage.* <-- Does not work.
...

WARNING!: You should be able to allow the ability to start and stop named services based on auth (solaris.smf.manage.telnet) but I have not been able to get this to work. I believe this is a bug.

Determining Your Roles, Auths, and Profiles

You can either use the roles, auths, and profiles commands: 

benr@aeon ~$ roles
zfs

benr@aeon ~$ auths 
solaris.admin.prodreg.read,solaris.admin.prodreg.modify,solaris.admin.prodreg.delete,solaris.admin.dcmgr.admin,solaris.admin.dcmgr.read,solaris.admin.patchmgr.*,solaris.device.cdrw,solaris.profmgr.read,solaris.jobs.user,solaris.mail.mailq,solaris.device.mount.removable,solaris.admin.usermgr.read,solaris.admin.logsvc.read,solaris.admin.fsmgr.read,solaris.admin.serialmgr.read,solaris.admin.diskmgr.read,solaris.admin.procmgr.user,solaris.compsys.read,solaris.admin.printer.read,solaris.snmp.read,solaris.project.read,solaris.admin.patchmgr.read,solaris.network.hosts.read,solaris.admin.volmgr.read

benr@aeon ~$ profiles 
Software Installation
Basic Solaris User
All

Or, just read /etc/user_attr directly: 

benr@aeon ~$ grep `id -u -n` /etc/user_attr 
benr::::type=normal;roles=zfs;profiles=Software Installation

REMEMBER!: Profiles are only recognized when used within a Profile Shell (pfsh, pfksh, pfcsh) or pfexec. This does not apply to authorizations however!

Common Examples

The following are collection of real-world examples in which RBAC can help.

Example 1: SMF Control

Say you want to give a user the ability to manipulate SMF services but not have other root privs (say, cat /etc/shadow). You could handle this in the following ways:

  1. Add a profile definition to /etc/user_attr, example: benr::::profiles=Service Management
  2. Add the profile definition direct to an existing user account, example: usermod -P "Service Management" benr
  3. Add all individual authorizations to an existing user account, example: usermod -A "solaris.smf.manage.font" benr

Lets discuss this last one a bit further. The first two methods are the same actually, in one case your editing directly user_attr and in the other your using usermod to do it for you. Both methods involve using the SMF Profile. In the 3rd case your using auths which are much more fine grained. Notice the following example: 

root@aeon security$ usermod -A "solaris.smf.manage.font" benr
UX: usermod: benr is currently logged in, some changes may not take effect until next login.


$ svcadm restart font/fc-cache            # THIS WORKS
$ svcadm restart dumpadm                  # THIS DOESN'T
svcadm: svc:/system/dumpadm:default: Permission denied.

You can create your own authorizations by adding them to auth_attr: 

solaris.smf.manage.http:::Manage HTTP service states::

Then added and tested: 

$ usermod -A solaris.smf.manage.http benr
UX: usermod: benr is currently logged in, some changes may not take effect until next login.

$ svcadm restart http

PLEASE NOTE: You can not, currently, use the above SMF method for multiple instances of a service because of an inability to properly parse /etc/user_attr, the ":" character isn't be properly escaped.


A Joyent user actually uses this method: Mongrel and SMF, meet RBAC, say goodbye to sudo

Example 2: Installing Packages Without Root

To install packages using Blastwave you must assume root, however using RBAC's exec_attr and a Profile we can avoid this. A Profile named "Software Installation" already exists for this task, however pkg-get itself isn't a part of it, thus we modify /etc/security/exec_attr: 

...
Software Installation:suser:cmd:::/usr/sbin/pkgask:uid=0
Software Installation:suser:cmd:::/usr/sbin/pkgchk:uid=0
Software Installation:suser:cmd:::/usr/sbin/pkgrm:uid=0;gid=bin
Software Installation:suser:cmd:::/opt/csw/bin/pkg-get:uid=0;gid=bin

We then associate this profile with a user or role: 

root@aeon ~$ usermod -P "Software Installation" benr
UX: usermod: benr is currently logged in, some changes may not take effect until next login.

And the proof... 

benr@aeon ~$ pfexec pkg-get -i bmon  
.... 
Using </opt/csw> as the package base directory.
## Processing package information.
## Processing system information.
   5 package pathnames are already properly installed.
## Verifying package dependencies.
## Verifying disk space requirements.
## Checking for conflicts with packages already installed.
## Checking for setuid/setgid programs.

Installing bmon - bandwidth monitor as <CSWbmon>

## Installing part 1 of 1.
/opt/csw/bin/bmon
/opt/csw/share/doc/bmon/examples/bmon.conf
/opt/csw/share/man/man1/bmon.1
[ verifying class <none> ]

Installation of <CSWbmon> was successful.


REMEMBER: Profiles are only effective if you are using a pf* shell or pfexec!!!

Delegating Network Admin Privileges

The "Network Management" Profile provides access to a variety of network related tools: 

benr@aeon ~$ grep "Network Management" /etc/security/exec_attr 
Network Management:solaris:cmd:::/sbin/dladm:euid=dladm;egid=sys;       privs=sys_net_config,net_rawaccess,proc_audit
Network Management:solaris:cmd:::/sbin/ifconfig:uid=0
Network Management:solaris:cmd:::/sbin/route:privs=sys_ip_config
Network Management:solaris:cmd:::/sbin/routeadm:euid=0; privs=proc_chroot,proc_owner,sys_ip_config
Network Management:solaris:cmd:::/usr/sbin/quaggaadm:privs=basic
Network Management:solaris:cmd:::/usr/sbin/zebraadm:privs=basic
Network Management:suser:cmd:::/usr/bin/netstat:uid=0
Network Management:suser:cmd:::/usr/bin/rup:euid=0
Network Management:suser:cmd:::/usr/bin/ruptime:euid=0
Network Management:suser:cmd:::/usr/bin/setuname:euid=0
Network Management:suser:cmd:::/usr/sbin/asppp2pppd:euid=0
Network Management:suser:cmd:::/usr/sbin/ifconfig:uid=0
Network Management:suser:cmd:::/usr/sbin/ipaddrsel:euid=0
Network Management:suser:cmd:::/usr/sbin/ipqosconf:euid=0
Network Management:suser:cmd:::/usr/sbin/rndc:privs=file_dac_read
Network Management:suser:cmd:::/usr/sbin/route:uid=0
Network Management:suser:cmd:::/usr/sbin/snoop:uid=0
Network Management:suser:cmd:::/usr/sbin/spray:euid=0
Network Management:suser:cmd:::/usr/share/setup-tool-backends/scripts/network-conf:uid=0

We can assign this profile thusly: 

root@aeon ~$ usermod -P "Network Management" benr
UX: usermod: benr is currently logged in, some changes may not take effect until next login.

After a logout and login, we can attempt using these new privs: 

benr@aeon ~$ dladm show-link
dladm: insufficient privileges
benr@aeon ~$ pfexec dladm show-link
nge0            type: non-vlan  mtu: 1500       device: nge0

RBAC & SMF

One notable exclusion from exec_attr are the svc* SMF commands. These are special and handled via authorizations. Two profiles wrap these for convince: 

Service Management:::Manage services:auths=solaris.smf.manage,solaris.smf.modify
Service Operator:::Administer services:auths=solaris.smf.manage,solaris.smf.modify.framework

The differentiator here is the ability to modify or insert new services as opposed to just changing service state.

You can give a user or role the ability to control SMF services by adding a new Authorization to '/etc/security/auth_attr by prefixing the service name with "solaris.smf.manage." Auths can provide even finer grained control by limit access to modifying various types of properties (ie: "solaris.smf.modify.dependency" to modify only the dependency property group). See smf_security(5) for full details.

Within a service manifest, in the method_context context you may specify privileges (priv set to associate) and limit_privileges.


See also: SMF & RBAC and SMF_Security(5) Man Page

Using RBAC Profiles in Non-PF Shells

In order to use RBAC Profiles you must utilize one of the provided "Profile Shells" (eg: pfsh, pfcsh, etc). Switching to one of these shells means giving up history tracking, tab completion, etc offered by more advanced shells like ZSH and BASH.

All hope is not lost however, thanks to pfexec and shell aliasing: 

benr@tamarah ~$ id
uid=100(benr) gid=1(other)
benr@tamarah ~$ echo $SHELL
/bin/bash

benr@tamarah ~$ zlogin z010101FB
[Connected to zone 'z010101FB' pts/4]
Last login: Mon Sep 10 23:35:37 on pts/4
                                __                       __ 
                       __      / /___  __  _____  ____  / /_
                    __/ /___  / / __ \/ / / / _ \/ __ \/ __/
                   /_  __/ /_/ / /_/ / /_/ /  __/ / / / /_  
                    /_/  \____/\____/\__, /\___/_/ /_/\__/  
                                    /____/ Accelerators
#

The key here is to alias any commands that you have access to (cross reference /etc/security/exec_attr with /etc/security/prof_attr): 

benr@tamarah ~$ profiles 
Zone Management
ZFS File System Management
Basic Solaris User
All

benr@tamarah ~$ grep "Zone Management" /etc/security/exec_attr 
Zone Management:solaris:cmd:::/usr/sbin/zlogin:uid=0
Zone Management:solaris:cmd:::/usr/sbin/zoneadm:uid=0
Zone Management:solaris:cmd:::/usr/sbin/zonecfg:uid=0
benr@tamarah ~$ grep "ZFS File System Management" /etc/security/exec_attr 
ZFS File System Management:solaris:cmd:::/sbin/zfs:euid=0

benr@tamarah ~$ alias 
alias zfs='pfexec zfs'
alias zlogin='pfexec zlogin'
alias zoneadm='pfexec zoneadm'
alias zonecfg='pfexec zonecfg'
....

RBAC for Sr Admins

Root permissions can be provided to Sr Admins such that they have root priveleges without using uid 0 via RBAC.

...

RBAC for Jr Admins

Permissions can be locked down for admins who should not have total root access by means of RBAC. They need to have the following privs:

  • Ability to administer Zones (start, stop, list, reboot) {Zone Management profile}
  • Ability to log into Zones (zlogin) {Zone Management profile}
  • Ability to modify ZFS filesystems (zfs set quota=...) {ZFS File System Management}

They should not have the ability to:

  • Interact with SMF in the globalzone (svcadm restart zones is bad)
  • Reboot or halt the globalzone
  • Modify security within the globalzone
  • Modify packages within the globalzone
  • etc.

User creation example: 

root@tamarah /$ useradd -d /home/benr -s /bin/bash -c 'Admin User' -P "Zone Management","ZFS File System Management" -m -d /home/benr benr
64 blocks
root@tamarah /$ passwd benr
New Password: 
Re-enter new Password: 
passwd: password successfully changed for benr

Then, if you choose to use BASH, use the following .bashrc/.bash_profile: 

## Prompts:
export PS1="\u@\h \W$ "

## Paths:
export PATH=/usr/bin:/usr/sbin:/usr/local/bin:/opt/csw/bin:/usr/ccs/bin:/usr/sfw/bin:/sbin

## General Purposes Aliases:
alias tar='gtar'
alias make='gmake'

## RBAC Aliases:
alias zoneadm='pfexec zoneadm'
alias zonecfg='pfexec zonecfg'
alias zlogin='pfexec zlogin'
alias zfs='pfexec zfs'

RBAC Security: Protection Against Abuse

root@www mail$ usermod -P "Primary Administrator" benr
UX: usermod: ERROR: benr is in use.  Cannot change it.

This is usermod trying to protect against a user acquiring root and then delegating control to himself. However, you can bypass this simply by editing /etc/user_attr directly.

Profile Shells

See [1] for Borne Shell Profile Code.

TODO: Integration of Profile Shell code into ZSH.

Shortcomings of Profile Shells

Shell executions are made with the authority given to you, but shell functions fall through, the most notable exception is cd. You can ls a protected directory or use files within it (for instances, as "Primary Administrator" you execute everything with uid=0), however you can't change into that directory (cd is not a binary command, its a shell function).

For this reason, even having unadulterated RBAC authority isn't as natural as becoming root.

See Also

Attribution

This content was donated by Joyent.

Retrieved from "http://wiki.genunix.org:8080/wiki/index.php/RBAC"
Personal tools