What is true/complete defs subject/object/role/capabilities

Submit your RBAC policies or suggest policy improvements

Moderators: spender, PaX Team

What is true/complete defs subject/object/role/capabilities

Postby in-grsecurity@baka.org » Sat Jul 31, 2004 1:57 pm

I have looked at the rather out of date stuff on the main web site, and furthermore even have found the secret home of the more correct temporary defintions: http://grsecurity.net/~spender/doc

However, even assembling the best of the information I can find, I have discovered that it is still insufficient. For example, it appears that the object flag `t' has something to do with mmap--whether it has any ptrace effects I do not know. I have suspicions about the definition of CAP_SYS_RAWIO capability. I will include the abbreviated summary which I have assembled from all known sources at the top of my policy file--a fine place for it IMHO. Corrections or additions (remember I know it has inaccuracies) would be most appreciated. I failed to assemble the bind/connect and resource limit documents in the information below.

I hope the formatting is not screwed up too much.

Code: Select all
######################################################################
# Subjects can be a file or directory.  All binaries or scripts matching
# that path will gain the permission of the subject upon execution
#
# Subject flags:
#
# o  -  Disable configuration inheritance
# h  -  Hide this process for all processes but those with the 'v' subject
#       flag
# p  -  Protect this process from all processes but those with the 'k'
#       mode
# k  -  Allow killing of protected processes
# b  -  Enable process accounting
# d  -  Protect /proc/<pid>/fd and /proc/<pid>/mem
# l  -  Enable learning
# P  -  Disable PAGEEXEC feature of PaX
# S  -  Disable SEGMEXEC feature of PaX
# M  -  Disable MPROTECT feature of PaX
# R  -  Disable RANDMMAP feature of PaX
# G  -  Enable EMUTRAMP feature of PaX
# X  -  Enable RANDEXEC feature of PaX
# O  -  Allow writable library loads and ptraces of other subjects
# A  -  Protect shared memory
# K  -  Auto-kill upon violation of security policy
# C  -  Auto-kill all processes belonging to attacker's IP address upon
#       violation of security policy
# T  -  Deny execution of binaries or scripts that are writable by any
#       other subject in the policy
#
######################################################################
# Object permission flags:
#
# r  -  Allow reads for this path
# w  -  Allow writes for this path (implies allowed append)
# a  -  Allow appends for this path
# c  -  Allow creates for this path
# d  -  Allow deletions for this path
# m  -  Allow creation of setuid/setgid files and addition of the
#       setuid/setgid bit for this path
# x  -  Allow executions for this path
# i  -  Inherit the current subject when executing for this path
# t  -  Reject only ptrace-writes for this path
# p  -  Reject all ptraces for this path
# h  -  Reject all access and hide this path
#
# Object auditing flags:
#
# R  -  Audit reads for this path
# W  -  Audit writes for this path (implies append auditing)
# A  -  Audit appends for this path
# C  -  Audit creates for this path
# D  -  Audit deletions for this path
# M  -  Audit creation of setuid/setgid files and addition of the
#       setuid/setgid bit for this path
# X  -  Audit executions for this path
# I  -  Audit inherits of the current subject when executing for this path
# F  -  Audit accesses that don't involve reading or writing for this path
#       (eg. stat, readdir, getdents, access)
#
# Other object flags:
#
# s  -  Suppress logs of denied access for this path
#
######################################################################
# Role flags:
# A -> This role is an administrative role, thus it has special privilege
#      normal roles do not have.  In particular, this role bypasses the
#      additional ptrace restrictions
# N -> Don't require authentication for this role.  To access
#      the role, use gradm -n <rolename>
# s -> This role is a special role, meaning it does not belong to a
#      user or group, and does not fall under ACL enforcement
# u -> This role is a user role
# g -> This role is a group role
# G -> This role can use gradm to authenticate to the kernel
#      An ACL for gradm will automatically be added to the role
# T -> Enable TPE for this role
# l -> Enable learning for this role
#
# a role can only be one of user, group, or special
#
# role_allow_ip IP/optional netmask
# eg: role_allow_ip 192.168.1.0/24
# You can have as many of these per role as you want
# They restrict the use of a role to a list of IPs.  If a user
# is on the system that would normally get the role does not
# belong to those lists of IPs, the system falls back through
# its method of determining a role for the user
#
# Role hierarchy
# user -> group -> default
# First a user role attempts to match, if one is not found,
# a group role attempts to match, if one is not found,
# the default role is used.
#
# role_transitions <special role 1> <special role 2> ... <special role n>
# eg: role_transitions www_admin dns_admin
#
# role transitions specify which special roles a given role is allowed
# to authenticate to.  This applies to special roles that do not
# require password authentication as well.  If a user tries to
# authenticate to a role that is not within his transition table, he
# will receive a permission denied error
#
# Nested subjects
# subject /bin/su:/bin/bash:/bin/cat
#         / rwx
#         +CAP_ALL
# grant privilege to specific processes if they are executed
# within a trusted path.  In this case, privilege is
# granted if /bin/cat is executed from /bin/bash, which is
# executed from /bin/su.
#
# Configuration inheritance on nested subjects
# nested subjects inherit rules from their parents.  In the
# example above, the nested subject would inherit rules
# from the nested subject for /bin/su:/bin/bash,
# and the subject /bin/su
#
# user/group transitions:
# You may now specify what users and groups a given subject can
# transition to.  This can be done on an inclusive or exclusive basis.
# Examples:
# subject /bin/su
# user_transition_allow root spender
# group_transition_allow root spender
# subject /bin/su
# user_transition_deny evilhacker
# subject /bin/su
# group_transition_deny evilhacker1 evilhacker2
#
######################################################################
# CAPABILITIES
#
#0.  CAP_CHOWN In a system with the [_POSIX_CHOWN_RESTRICTED] option
#    defined, this overrides the restriction of changing file
#    ownership and group ownership.
#
#1.  CAP_DAC_OVERRIDE Override all DAC (Discretionary Access Control
#    or std unix access control) access, including ACL execute access
#    if [_POSIX_ACL] is defined. Excluding DAC access covered by
#    CAP_LINUX_IMMUTABLE.
#
#2.  CAP_DAC_READ_SEARCH Overrides all DAC restrictions, regarding
#    read and search on files and directories, including ACL
#    restrictions, if [_POSIX_ACL] is defined. Excluding DAC access
#    covered by CAP_LINUX_IMMUTABLE.
#
#3.  CAP_FOWNER Overrides all restrictions about allowed operations on
#    files, where file owner ID must be equal to the user ID, except
#    where CAP_FSETID is applicable. It doesn't override MAC and DAC
#    restrictions.
#
#4.  CAP_FSETID Overrides the following restrictions, that the
#    effective user ID shall match the file owner ID, when setting the
#    S_ISUID and S_ISGID bits on that file; that the effective group
#    ID (or one of the supplementary group IDs) shall match the file
#    owner ID when setting the S_ISGID bit on that file; that the
#    S_ISUID and S_ISGID bits are cleared on successful return from
#    chown(2) (not implemented).
#
#5.  CAP_KILL Overrides the restriction, that the real or effective
#    user ID of a process, sending a signal, must match the real or
#    effective user ID of the process, receiving the signal.
#
#6.  CAP_SETGID
#
#       Allows setgid(2) manipulation;
#
#       Allows setgroups(2);
#
#       Allows forged gids on socket credentials passing.
#
#7.  CAP_SETUID
#
#       Allows set*uid(2) manipulation (including fsuid);
#
#       Allows forged pids on socket credentials passing.
#
#8.  CAP_SETPCAP Transfer any capability in your permitted set to any
#    pid, remove any capability in your permitted set from any pid.
#
#9.  CAP_LINUX_IMMUTABLE Allow modification of S_IMMUTABLE and
#    S_APPEND file attributes.
#
#10.  CAP_NET_BIND_SERVICE
#
#       Allows binding to TCP/UDP sockets below 1024;
#
#       Allows binding to ATM VCIs below 32.
#
#11.  CAP_NET_BROADCAST  Allow broadcasting, listen to multicast.
#
#12.  CAP_NET_ADMIN
#
#       Allow interface configuration;
#
#       Allow administration of IP firewall, masquerading and accounting;
#
#       Allow setting debug option on sockets;
#
#       Allow modification of routing tables;
#
#       Allow setting arbitrary process / process group ownership on sockets;
#
#       Allow binding to any address for transparent proxying;
#
#       Allow setting TOS (type of service);
#
#       Allow setting promiscuous mode;
#
#       Allow clearing driver statistics;
#
#       Allow multicasting;
#
#       Allow read/write of devicespecific registers;
#
#       Allow activation of ATM control sockets.
#
#13.  CAP_NET_RAW
#
#       Allow use of RAW sockets;
#
#       Allow use of PACKET sockets.
#
#14.  CAP_IPC_LOCK
#
#       Allow locking of shared memory segments;
#
#       Allow mlock and mlockall (which doesn't really have anything
#       to do with IPC).
#
#15.  CAP_IPC_OWNER  Override IPC ownership checks.
#
#16.  CAP_SYS_MODULE
#
#       Insert and remove kernel modules  modify kernel without limit;
#
#       Modify cap_bset.
#
#17.  CAP_SYS_RAWIO
#
#       Allow ioperm/iopl access;
#
#       Allow sending USB messages to any device via /proc/bus/usb.
#
#18.  CAP_SYS_CHROOT  Allow use of chroot().
#
#19.  CAP_SYS_PTRACE  Allow ptrace() of any process.
#
#20.  CAP_SYS_PACCT  Allow configuration of process accounting.
#
#21. CAP_SYS_ADMIN
#
#       Allow configuration of the secure attention key;
#
#       Allow administration of the random device;
#
#       Allow examination and configuration of disk quotas;
#
#       Allow configuring the kernel's syslog (printk behaviour);
#
#       Allow setting the domainname;
#
#       Allow setting the hostname;
#
#       Allow calling bdflush();
#
#       Allow mount() and umount(), setting up new smb connection;
#
#       Allow some autofs root ioctls;
#
#       Allow nfsservctl; Allow VM86_REQUEST_IRQ;
#
#       Allow to read/write pci config on alpha; Allow irix_prctl on
#       mips (setstacksize);
#
#       Allow flushing all cache on m68k (sys_cacheflush);
#
#       Allow removing semaphores; Used instead of CAP_CHOWN to
#       "chown" IPC message queues, semaphores and shared memory;
#
#       Allow locking/unlocking of shared memory segment;
#
#       Allow turning swap on/off;
#
#       Allow forged pids on socket credentials passing;
#
#       Allow setting readahead and flus
#
######################################################################

[/code]
--Seth Robertson
in-grsecurity@baka.org
 
Posts: 10
Joined: Sat Jul 31, 2004 1:25 am

Re: What is true/complete defs subject/object/role/capabilit

Postby PaX Team » Sun Aug 01, 2004 9:04 am

in-grsecurity@baka.org wrote:I have looked at the rather out of date stuff on the main web site, and furthermore even have found the secret home of the more correct temporary defintions: http://grsecurity.net/~spender/doc
it's not secret, it's just under development, and won't be released 'officially' until grsecurity for 2.4.27/2.6.7 is out. if you want to track the development this closely then better hang around in #grsecurity at oftc.
For example, it appears that the object flag `t' has something to do with mmap--whether it has any ptrace effects I do not know.
't' denies ptrace requests that want to write the memory or registers of the target process, reads are allowed otherwise, so strace will work on them but gdb won't be able to set breakpoints for example. the rest will have to wait for spender, hopefully he survives defcon ;-).
PaX Team
 
Posts: 2310
Joined: Mon Mar 18, 2002 4:35 pm

Postby spender » Tue Aug 03, 2004 1:36 am

't' has nothing to do with mmap, just ptrace. Not sure what you meant about CAP_SYS_RAWIO, but on a grsec-enabled machine CAP_SYS_RAWIO is also required to open a block device.

-Brad
spender
 
Posts: 2185
Joined: Wed Feb 20, 2002 8:00 pm
Location: VA, USA

Postby in-grsecurity@baka.org » Wed Aug 04, 2004 10:20 am

spender wrote:'t' has nothing to do with mmap, just ptrace. Not sure what you meant about CAP_SYS_RAWIO, but on a grsec-enabled machine CAP_SYS_RAWIO is also required to open a block device.

-Brad


I added 't' (as suggested by the learning system) but failed to remove the subject learning flag so I assumed that change allowed it to work. Oops.

However, now I do not understand why the configuration I wrote failed. I changed a '*' expansion to an explicitly named expansion and that allowed the system to work. I believe that '*' expansion is not totally broken, but why didn't it work in this case?

Failing configuration:
-------------------------------------------------------
Code: Select all
subject /no/sandbox/p2p o {
        /no/sandbox/p2p/dev/urandom r
        /no/sandbox/p2p/etc r
        /no/sandbox/p2p/lib rx
        /no/sandbox/p2p/tmp rwcd
        /no/sandbox/p2p/usr
        /no/sandbox/p2p/usr/bin
        /no/sandbox/p2p/usr/bin/btdownloadcurses.py r
        /no/sandbox/p2p/usr/bin/python2.* xt
        /no/sandbox/p2p/usr/bin/python rxt
        /no/sandbox/p2p/usr/lib r
        /no/sandbox/p2p/usr/lib/gcc-lib rx
        /no/sandbox/p2p/usr/lib/lib*.so.* rx
        /no/sandbox/p2p/usr/lib/portage/pym
        /no/sandbox/p2p/usr/lib/python2.* r
        /no/sandbox/p2p/usr/lib/python2.*/lib-dynload rx
        /no/sandbox/p2p/usr/lib/python2.*/site-packages/BitTorrent rwcd
        /no/sandbox/p2p/usr/share/terminfo r
        / h
        -CAP_ALL

        connect 0.0.0.0/0:1025-65535 stream tcp
        connect 0.0.0.0/0:80-81 stream tcp
        connect 0.0.0.0/0:443 stream tcp
        bind 0.0.0.0:6880-6896 stream tcp
        bind 0.0.0.0:0 dgram ip
}

-------------------------------------------------------

Difference which allows the system to work:
-------------------------------------------------------
Code: Select all
--- policy      2004/08/04 14:32:32     1.3
+++ policy      2004/08/04 14:32:48
@@ -980,7 +980,7 @@
        /no/sandbox/p2p/usr/lib/lib*.so.* rx
        /no/sandbox/p2p/usr/lib/portage/pym
        /no/sandbox/p2p/usr/lib/python2.* r
-       /no/sandbox/p2p/usr/lib/python2.*/lib-dynload rx
+       /no/sandbox/p2p/usr/lib/python2.3/lib-dynload rx
        /no/sandbox/p2p/usr/lib/python2.*/site-packages/BitTorrent rwcd
        /no/sandbox/p2p/usr/share/terminfo r
        / h

-------------------------------------------------------
--Seth Robertson
in-grsecurity@baka.org
 
Posts: 10
Joined: Sat Jul 31, 2004 1:25 am

Postby spender » Wed Aug 04, 2004 10:50 am

/no/sandbox/p2p/usr/lib/python2.* r
/no/sandbox/p2p/usr/lib/python2.*/lib-dynload rx

Both of those globbed objects will be attached to /no/sandbox/p2p/usr/lib. They are checked in a linear fashion, and my guess is that it found python2.* first and it matched. Try switching their order around and see if that changes it.

-Brad
spender
 
Posts: 2185
Joined: Wed Feb 20, 2002 8:00 pm
Location: VA, USA

Postby in-grsecurity@baka.org » Wed Aug 04, 2004 11:03 am

spender wrote:Try switching their order around and see if that changes it.

-Brad


That worked. Thanks! (though I might suggest changing the attach order so that the order the file is written in is the same order as the rules are checked--either that or sort the attachment so that longest-match goes first).
--Seth Robertson
in-grsecurity@baka.org
 
Posts: 10
Joined: Sat Jul 31, 2004 1:25 am

Postby spender » Wed Aug 04, 2004 8:02 pm

I've just updated current CVS to reorder the globbed object list so that it matches the most specific match first. Can you verify it for your configuration? (switch around the order of the two rules to make sure)

-Brad
spender
 
Posts: 2185
Joined: Wed Feb 20, 2002 8:00 pm
Location: VA, USA

Postby in-grsecurity@baka.org » Thu Aug 05, 2004 12:39 am

Is this a kernel or a gradm fix? gradm is a lot easier to test...
--Seth Robertson
in-grsecurity@baka.org
 
Posts: 10
Joined: Sat Jul 31, 2004 1:25 am

Postby spender » Thu Aug 05, 2004 9:09 pm

gradm

-Brad
spender
 
Posts: 2185
Joined: Wed Feb 20, 2002 8:00 pm
Location: VA, USA


Return to RBAC policy development

cron