Role-Based Access Control (RBAC)
Role-based access control (RBAC) is a method that allows and restricts access to subjects or users based on the role of the user. When reading, pay attention to the description of an RBAC system and be able to describe the system, as well as to name the user that only RBAC can restrict. How does this one restriction increase the difficulty for an attacker to compromise the system? What is the set of rules called that manages the RBAC system? Although you will not be asked to create an RBAC policy, read through the rest of the document and try to follow the examples of how an RBAC policy is coded on a system.
14. Sample Policies
Below is the sample policy provided with a gradm installation:
role admin sA
subject / rvka
/ rwcdmlxi
role default G
role_transitions admin
subject /
/ r
/opt rx
/home rwxcd
/mnt rw
/dev
/dev/grsec h
/dev/urandom r
/dev/random r
/dev/zero rw
/dev/input rw
/dev/psaux rw
/dev/null rw
/dev/tty? rw
/dev/console rw
/dev/tty rw
/dev/pts rw
/dev/ptmx rw
/dev/dsp rw
/dev/mixer rw
/dev/initctl rw
/dev/fd0 r
/dev/cdrom r
/dev/mem h
/dev/kmem h
/dev/port h
/bin rx
/sbin rx
/lib rx
/usr rx
# compilation of kernel code should be done within the admin role
/usr/src h
/etc rx
/proc rwx
/proc/slabinfo h
/proc/kcore h
/proc/modules h
/proc/sys r
/root r
/tmp rwcd
/var rwxcd
/var/tmp rwcd
/var/log r
# hide the kernel images and modules
/boot h
/lib/modules h
/etc/grsec h
/etc/ssh h
# if sshd needs to be restarted, it can be done through the admin role
# restarting sshd should be followed immediately by a gradm -u
/usr/sbin/sshd
-CAP_KILL
-CAP_SYS_TTY_CONFIG
-CAP_LINUX_IMMUTABLE
-CAP_NET_RAW
-CAP_MKNOD
-CAP_SYS_ADMIN
-CAP_SYS_RAWIO
-CAP_SYS_MODULE
-CAP_SYS_PTRACE
-CAP_NET_ADMIN
-CAP_NET_BIND_SERVICE
-CAP_NET_RAW
-CAP_SYS_CHROOT
-CAP_SYS_BOOT
# RES_AS 100M 100M
# connect 192.168.1.0/24:22 stream tcp
# bind 0.0.0.0 stream dgram tcp udp
# the d flag protects /proc fd and mem entries for sshd
# all daemons should have 'p' in their subject mode to prevent
# an attacker from killing the service (and restarting it with trojaned
# config file or taking the port it reserved to run a trojaned service)
subject /usr/sbin/sshd dpo
/ h
/bin/bash x
/dev h
/dev/log rw
/dev/random r
/dev/urandom r
/dev/null rw
/dev/ptmx rw
/dev/pts rw
/dev/tty rw
/dev/tty? rw
/etc r
/etc/grsec h
/home
/lib rx
/root
/proc r
/proc/kcore h
/proc/sys h
/usr/lib rx
/usr/share/zoneinfo r
/var/log
/var/mail
/var/log/lastlog rw
/var/log/wtmp w
/var/run/sshd
/var/run/utmp rw
-CAP_ALL
+CAP_CHOWN
+CAP_SETGID
+CAP_SETUID
+CAP_SYS_CHROOT
+CAP_SYS_RESOURCE
+CAP_SYS_TTY_CONFIG
subject /usr/X11R6/bin/XFree86
/dev/mem rw
+CAP_SYS_ADMIN
+CAP_SYS_TTY_CONFIG
+CAP_SYS_RAWIO
-PAX_SEGMEXEC
-PAX_PAGEEXEC
-PAX_MPROTECT
subject /usr/bin/ssh
/etc/ssh/ssh_config r
subject /sbin/klogd
+CAP_SYS_ADMIN
subject /sbin/syslog-ng
+CAP_SYS_ADMIN
subject /usr/sbin/cron
/dev/log rw
subject /bin/login
/dev/log rw
/var/log/wtmp w
/var/log/faillog rwcd
subject /sbin/getty
/var/log/wtmp w
subject /sbin/init
/var/log/wtmp w
Below is a full user role policy that covers the behavior of cvs-pserver when run as the non-root cvs user, providing anonymous read-only CVS repository access.
role cvs u
subject /
/ h
-CAP_ALL
connect disabled
bind disabled
subject /usr/bin/cvs
/
/etc/fstab r
/etc/mtab r
/etc/passwd r
/proc/meminfo r
/dev/urandom r
/dev/log rw
/dev/null rw
/home/cvs r
/home/cvs/CVSROOT/val-tags rw
/home/cvs/CVSROOT/history ra
/tmp rwcd
/var/lock/cvs rwcd
/var/run/.nscd_socket rw
/proc/sys/kernel r
/var/run
Here's all that's needed for an unprivileged sshd account:
role sshd u
subject /
/ h
/var/run/sshd r
-CAP_ALL
bind disabled
connect disabled