The refpolicy repository is still svn. heres how to use git together with svn.
1. use git svn to clone the refpolicy svn repository:
mkdir ~/git
cd ~/git
git svn clone http://oss.tresys.com/repos/refpolicy/trunk refpolicy
cd ~/git/refpolicy
git branch (to see if master is there)
git branch -r (to see if remote branch (git-svn) is there)
2. create a branch to work on.
git svn checkout -b mybranch git-svn
3. add changes and commit them
git commit
4. create a patch with your modification (your changes from master in this case)
git format-patch master
5. update master and git-svn (remote branche)
git svn fetch
note eclipse-egit is a eclipse plugin that allows you to load, work on a git branch in eclipse and commit.
vrijdag 25 juli 2008
dinsdag 22 juli 2008
rbac f9
Let us assume we want to make user "joe" our website operator.
"joe" should only be able to operate apache.
To operate apache one traditionally would need a root password.
In fedora 9 root can be confined to specific roles.
Also in Fedora 9 user no longer need a root password to gain root
privileges due to SELinux support built-in sudo.
Pre-Fedora 9 a combination of su and newrole was used to gain root
privileges. This required a user to enter his password for newrole and
then also the root password for su.
Here is how you do it:
1. useradd joe
2. passwd joe
3. /usr/sbin/semanage user -a -L s0 -r s0-s0 -R "staff_r webadm_r" -P
user webadmin
4. /usr/sbin/semanage login -a -s webadmin -r s0-s0 joe
5. echo "joe ALL=(all) TYPE=webadm_t ROLE=webadm_r ALL" >> /etc/sudoers
When joe logs into the system, he will find himself in the staff_t user
domain (id -Z). This is a restricted user domain. The staff_r role is
similar to the user_r with the important exeption that staff_r may
transition to other , maybe more privileged, domain. unlike user_r.
user_r is confined to the user_t user domain, and may not transition.
If joe wants to, for example, restart the webserver, he can just type
sudo service httpd restart. Similar if joe wanted to edit a file that is
owned by apache, joe can edit the file in the webadm_t userdomain by
just typing sudo vi /etc/httpd/conf.d/httpd.conf.
Joe can also open a terminal session in the webadm_t domain by running:
sudo sh. If you would have even more roles, then joe would be able to
define in which user domain he wants to start a new terminal session:
sudo -t webadm_t -r webadm_r sh
Joe can even login to the system directly in the webadm_t domain by
using: ssh joe/webadm_r@localhost
You can delegate very specific administration tasks without having to
share the root password!
"joe" should only be able to operate apache.
To operate apache one traditionally would need a root password.
In fedora 9 root can be confined to specific roles.
Also in Fedora 9 user no longer need a root password to gain root
privileges due to SELinux support built-in sudo.
Pre-Fedora 9 a combination of su and newrole was used to gain root
privileges. This required a user to enter his password for newrole and
then also the root password for su.
Here is how you do it:
1. useradd joe
2. passwd joe
3. /usr/sbin/semanage user -a -L s0 -r s0-s0 -R "staff_r webadm_r" -P
user webadmin
4. /usr/sbin/semanage login -a -s webadmin -r s0-s0 joe
5. echo "joe ALL=(all) TYPE=webadm_t ROLE=webadm_r ALL" >> /etc/sudoers
When joe logs into the system, he will find himself in the staff_t user
domain (id -Z). This is a restricted user domain. The staff_r role is
similar to the user_r with the important exeption that staff_r may
transition to other , maybe more privileged, domain. unlike user_r.
user_r is confined to the user_t user domain, and may not transition.
If joe wants to, for example, restart the webserver, he can just type
sudo service httpd restart. Similar if joe wanted to edit a file that is
owned by apache, joe can edit the file in the webadm_t userdomain by
just typing sudo vi /etc/httpd/conf.d/httpd.conf.
Joe can also open a terminal session in the webadm_t domain by running:
sudo sh. If you would have even more roles, then joe would be able to
define in which user domain he wants to start a new terminal session:
sudo -t webadm_t -r webadm_r sh
Joe can even login to the system directly in the webadm_t domain by
using: ssh joe/webadm_r@localhost
You can delegate very specific administration tasks without having to
share the root password!
a script
#!/bin/bash
# -xv
#
# Name: loginaccounts.sh
# Description: automate login account management
#
# Author: Dominick Grift
# Version: 0.0.3
# Copyright (C) 2008 Dominick Grift
# This program is free software: you can redistribute it and/or modify
# it under the terms of the GNU Affero General Public License as
# published by the Free Software Foundation, either version 3 of the
# License, or (at your option) any later version.
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
# GNU Affero General Public License for more details.
# You should have received a copy of the GNU Affero General Public License
# along with this program. If not, see
# Report undefined variables
# shopt -s -o nounset
# Global declarations
declare -rx SCRIPT=${0##*/}
declare -rx EXITSTATUS=$?
# My global declarations
declare -r OPTSTRING="-h,-L.-P,-A,-C,-f,-a,-i:,-p:,-c:,-g:,-l:,-n:,-c:,-q:,-e:"
declare UCOMMNT=0 # Optional
declare UGRP="realusers,sshusers" # Tunable
declare USERID # Mandatory
declare RESULT # System
declare UPASSWD # Mandatory
declare ULOGNS=3 # Tunable
declare UNPROC=15 # Tunable
declare ULOCL=0 # Optional
declare UCATGR=0 # Optional
declare UFORWRD=0 # optional
declare UQUOT="10000" # Tunable
declare UEXPR=0 # Optional
declare UPOLY=1 # Optional
declare UCRON=0 # Optional
declare UAT=0 # Optional
declare UAGE=1 # Optional
# Sanity checks
# Requires BASH
if test -z "$BASH" ; then
printf "$SCRIPT:$LINENO: %s\n" "Please run this script with the BASH shell" >&2
exit 192
fi
# Test for input
if test -z "$1" ; then
printf "$SCRIPT:$LINENO: %s\n" "Copyright (C) 2008 Dominick Grift"
printf "$SCRIPT:$LINENO: %s\n" ""
printf "$SCRIPT:$LINENO: %s\n" "This program is free software: you can redistribute it and/or modify"
printf "$SCRIPT:$LINENO: %s\n" "it under the terms of the GNU Affero General Public License as"
printf "$SCRIPT:$LINENO: %s\n" "published by the Free Software Foundation, either version 3 of the"
printf "$SCRIPT:$LINENO: %s\n" "License, or (at your option) any later version."
printf "$SCRIPT:$LINENO: %s\n" ""
printf "$SCRIPT:$LINENO: %s\n" "This program is distributed in the hope that it will be useful,"
printf "$SCRIPT:$LINENO: %s\n" "but WITHOUT ANY WARRANTY; without even the implied warranty of"
printf "$SCRIPT:$LINENO: %s\n" "MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the"
printf "$SCRIPT:$LINENO: %s\n" "GNU Affero General Public License for more details."
printf "$SCRIPT:$LINENO: %s\n" ""
printf "$SCRIPT:$LINENO: %s\n" "You should have received a copy of the GNU Affero General Public License"
printf "$SCRIPT:$LINENO: %s\n" "along with this program. If not, see
exit 0
fi
# Test for root
if [ `whoami` != "root" ] ; then
printf "$SCRIPT:$LINENO: %s\n" "DAC: Must be root" >&2
exit 192
fi
# Test for unconfined
if [ `id -Z | awk 'BEGIN { FS=":" } { print $3 }'` != unconfined_t ] ; then
printf "$SCRIPT:$LINENO: %s\n" "MAC: Must be unconfined domain" >&2
exit 192
fi
# Check getopt mode
getopt -T
if [ $? -ne 4 ] ; then
printf "$SCRIPT: %s\n" "Getopt is in compatibility mode" >&2
exit 192
fi
# Test parameters
RESULT='getopt --name "$SCRIPT" --options "$OPTSTRING" --longoptions "help" "identity" "password" "comment" "groups" "logins" "nproc" "local" "range" "forward" "quota" "expire" "poly" "cron" "at" "chage" -- "$@"'
if [ $? -gt 0 ] ; then
exit 192
fi
# Functions
add_user() {
/usr/sbin/useradd "$USERID" 1>&2 >/dev/null;
}
add_user_passwd() {
/bin/echo "$UPASSWD" | /usr/bin/passwd "$USERID" --stdin 1>&2 >/dev/null;
}
add_comment() {
/usr/sbin/usermod -c "$UCOMMNT" "$USERID" 1>&2 >/dev/null;
}
add_expire() {
/usr/sbin/usermod -e "$UEXPR" "$USERID" 1>&2 >/dev/null;
}
add_poly() {
/bin/mkdir /home/"$USERID"/"$USERID".inst && chmod -R 000 /home/"$USERID"/"$USERID".inst 1>&2 >/dev/null;
}
no_poly() {
/bin/sed '/^\/tmp/s/$/\,$USERID/' /etc/security/namespace.conf > tmpfile && /bin/cp tmpfile /etc/security/namespace.conf; /bin/rm tmpfile;
/bin/sed '/^\/var/s/$/\,$USERID/' /etc/security/namespace.conf > tmpfile && /bin/cp tmpfile /etc/security/namespace.conf; /bin/rm tmpfile;
/bin/sed '/^\$HOME/s/$/\,$USERID/' /etc/security/namespace.conf > tmpfile && /bin/cp tmpfile /etc/security/namespace.conf; /bin/rm tmpfile;
}
add_forward() {
/bin/echo """
Match User $USERID
X11Forwarding no
AllowTcpForwarding no""" >> /etc/ssh/sshd_config;
}
add_quota() {
/usr/sbin/setquota -u "$USERID" 0 "$UQUOT" 7500 10000 -a 1>&2 >/dev/null;
}
add_nproc() {
/bin/echo "$USERID hard nproc $UNPROC" >> /etc/security/limits.conf;
}
add_logins() {
/bin/echo "$USERID - maxlogins $ULOGNS" >> /etc/security/limits.conf;
}
add_local() {
/bin/echo "- : $USERID : LOCAL" >> /etc/security/access.conf;
}
add_cron() {
/bin/echo "$USERID" >> /etc/cron.allow;
}
add_at() {
/bin/echo "$USERID" >> /etc/at.allow;
}
add_groups() {
/usr/sbin/usermod -G "$UGRP" "$USERID" 1>&2 >/dev/null;
}
add_cat() {
NEWCAT=:$UCATGR
/usr/sbin/semanage user -a -L s0 -r "s0-s0$NEWCAT" -R user_r -P user "$USERID" 1>&2 >/dev/null;
/usr/sbin/semanage login -a -s "$USERID" -r "s0-s0$NEWCAT" "$USERID" 1>&2 >/dev/null;
}
add_seuser() {
/usr/sbin/semanage user -a -L s0 -r "s0-s0" -R user_r -P user "$USERID" 1>&2 >/dev/null;
/usr/sbin/semanage login -a -s "$USERID" -r "s0-s0" "$USERID" 1>&2 >/dev/null;
}
add_chage() {
/usr/bin/chage -m 7 -M 180 -W 7 "$USERID" 1>&2 >/dev/null;
}
# Main loop
# Replace the parameters with the results of getopt
eval set -- "$RESULT"
# Process the parameters
while [ $# -gt 0 ] ; do
case "$1" in
-h | --help) # Show help
printf "$SCRIPT:$LINENO: %s\n" "Usage: $SCRIPT [options]"
printf "$SCRIPT:$LINENO: %s\n" ""
printf "$SCRIPT:$LINENO: %s\n" " Options:"
printf "$SCRIPT:$LINENO: %s\n" " [-h][--help] | View this help"
printf "$SCRIPT:$LINENO: %s\n" " [-L][--local] | Optional: Disabled by default"
printf "$SCRIPT:$LINENO: %s\n" " [-f][--forward] | Optional: Disabled by default"
printf "$SCRIPT:$LINENO: %s\n" " [-P][--poly] | Optional: Enabled by default"
printf "$SCRIPT:$LINENO: %s\n" " [-C][--cron] | Optional: Disabled by default"
printf "$SCRIPT:$LINENO: %s\n" " [-A][--at] | Optional: Disabled by default"
printf "$SCRIPT:$LINENO: %s\n" " [-a][--chage] | Optional: Enabled by default"
printf "$SCRIPT:$LINENO: %s\n" " [-i][--identity] identity | Mandatory: User name"
printf "$SCRIPT:$LINENO: %s\n" " [-p][--password] password | Mandatory: Strong password"
printf "$SCRIPT:$LINENO: %s\n" " [-c][--comment] comment | Tunable: Defaults to none"
printf "$SCRIPT:$LINENO: %s\n" " [-g][--groups] groups | Tunable: Defaults to realusers,sshusers"
printf "$SCRIPT:$LINENO: %s\n" " [-l][--logins] number of logins | Tunable: Defaults to 3"
printf "$SCRIPT:$LINENO: %s\n" " [-n][--nproc] number of processes| Tunable: Defaults to 15"
printf "$SCRIPT:$LINENO: %s\n" " [-r][--range] range | Optional: Disabled by default"
printf "$SCRIPT:$LINENO: %s\n" " [-q][--quota] number of blocks | Tunable: Defaults to 10000 blocks"
printf "$SCRIPT:$LINENO: %s\n" " [-e][--expire] date | Optional: Disabled by default"
printf "$SCRIPT:$LINENO: %s\n" ""
printf "$SCRIPT:$LINENO: %s\n" " Examples:"
printf "$SCRIPT:$LINENO: %s\n" " $SCRIPT -i john -c \"John Doe\" -p F000_Bar!!1 -r c2,c4 -e 2010-12-15 -C"
exit 0
;;
-i | --identity) shift
if [ $# -eq 0 ] ; then
printf "$SCRIPT:$LINENO: %s\n" "Identity for [-i][--identity] is missing" >&2
exit 192
fi
USERID="$1"
;;
-p | --password) shift
if [ $# -eq 0 ] ; then
printf "$SCRIPT:$LINENO: %s\n" "Password for [-p][--password] is missing" >&2
exit 192
fi
UPASSWD="$1"
;;
-c | --comment) shift
if [ $# -eq 0 ] ; then
printf "$SCRIPT:$LINENO: %s\n" "Comment for [-c][--comment] is missing" >&2
exit 192
fi
UCOMMNT="$1"
;;
-g | --groups) shift
if [ $# -eq 0 ] ; then
printf "$SCRIPT:$LINENO: %s\n" "Groups for [-g][--groups] are missing" >&2
exit 192
fi
UGRP="$1"
;;
-l | --logins) shift
if [ $# -eq 0 ] ; then
printf "$SCRIPT:$LINENO: %s\n" "Number of logins for [-l][--logins] is missing" >&2
exit 192
fi
ULOGNS="$1"
;;
-n | --nproc) shift
if [ $# -eq 0 ] ; then
printf "$SCRIPT:$LINENO: %s\n" "Number of processes for [-n][--nproc] is missing" >&2
exit 192
fi
UNPROC="$1"
;;
-L | --local) shift
ULOCL=1
;;
-P | --poly) shift
UPOLY=0
;;
-r | --range) shift
if [ $# -eq 0 ] ; then
printf "$SCRIPT:$LINENO: %s\n" "Range for [-r][--range] is missing" >&2
exit 192
fi
UCATGR="$1"
;;
-f | --forward) shift
UFORWRD=1
;;
-C | --cron) shift
UCRON=1
;;
-A | --at) shift
UAT=1
;;
-a | --chage) shift
UAGE=0
;;
-q | --quota) shift
if [ $# -eq 0 ] ; then
printf "$SCRIPT:$LINENO: %s\n" "Quota for [-q][--quota] is missing" >&2
exit 192
fi
UQUOT="$1"
;;
-e | --expire) shift
if [ $# -eq 0 ] ; then
printf "$SCRIPT:$LINENO: %s\n" "Expiration date for [-e][--expire] is missing" >&2
exit 192
fi
UEXPR="$1"
;;
esac
shift
done
if [ -z "$USERID" ] ; then
printf "$SCRIPT:$LINENO: %s\n" "Identity missing" >&2
exit 192
fi
if [ -z "$UPASSWD" ] ; then
printf "$SCRIPT:$LINENO: %s\n" "Password missing" >&2
exit 192
fi
# Processing
if test -n "$USERID" ; then
add_user;
if [ $? -gt 0 ] ; then
printf "$SCRIPT:$LINENO: %s\n" "add_user: FAIL";
exit 192
fi
printf "$SCRIPT:$LINENO: %s\n" "added user: $USERID";
else
printf "$SCRIPT:$LINENO: %s\n" "no identity specified: should not be here";
exit 192
fi
sleep 1;
if test -n "$UPASSWD" ; then
add_user_passwd;
if [ $? -gt 0 ] ; then
printf "$SCRIPT:$LINENO: %s\n" "add_passwd: FAIL";
exit 192
fi
printf "$SCRIPT:$LINENO: %s\n" "added passwd: $UPASSWD";
else
printf "$SCRIPT:$LINENO: %s\n" "no password specified: should not be here";
exit 192
fi
sleep 1;
if test "$UCOMMNT" -ne 0 ; then
add_comment;
if [ $? -gt 0 ] ; then
printf "$SCRIPT:$LINENO: %s\n" "add_comment: FAIL";
exit 192
fi
printf "$SCRIPT:$LINENO: %s\n" "added comment: $UCOMMNT";
else
printf "$SCRIPT:$LINENO: %s\n" "no comment specified: skipping";
fi
sleep 1;
if [ "$UGRP" != "realusers,sshusers" ] ; then
add_groups;
if [ $? -gt 0 ] ; then
printf "$SCRIPT:$LINENO: %s\n" "add_groups: FAIL";
exit 192
fi
printf "%s\n" "added groups: $UGRP";
else
add_groups;
if [ $? -gt 0 ] ; then
printf "$SCRIPT:$LINENO: %s\n" "add_groups: FAIL";
exit 192
fi
printf "$SCRIPT:$LINENO: %s\n" "no groups specified: realusers,sshusers";
fi
sleep 1;
if [ "$UEXPR" != "0" ] ; then
add_expire;
if [ $? -gt 0 ] ; then
printf "$SCRIPT:$LINENO: %s\n" "add_expire: FAIL";
exit 192
fi
printf "$SCRIPT:$LINENO: %s\n" "added expire: $UEXPR";
else
printf "$SCRIPT:$LINENO: %s\n" "no expire specified: skipping";
fi
sleep 1;
if [ "$UPOLY" -eq 1 ] ; then
add_poly;
if [ $? -gt 0 ] ; then
printf "$SCRIPT:$LINENO: %s\n" "add_poly: FAIL";
exit 192
fi
printf "$SCRIPT:$LINENO: %s\n" "poly not specified: enabled poly"
else
no_poly;
printf "$SCRIPT:$LINENO: %s\n" "poly specified: disabled poly";
fi
sleep 1;
if [ "$UFORWRD" -lt 1 ] ; then
add_forward;
if [ $? -gt 0 ] ; then
printf "$SCRIPT:$LINENO: %s\n" "add forward: FAIL";
exit 192
fi
printf "$SCRIPT:$LINENO: %s\n" "forward not specified: added forward";
else
printf "$SCRIPT:$LINENO: %s\n" "forward specified: skipping";
fi
sleep 1;
if test "$UQUOT" -ne 10000 && test "$UQUOT" -n 0 ; then
add_quota;
if [ $? -gt 0 ] ; then
printf "$SCRIPT:$LINENO: %s\n" "add_quota: FAIL";
exit 192
fi
printf "$SCRIPT:$LINENO: %s\n" "added quota: $UQUOT"
elif [ "$UQUOT" -ne 0 ] ; then
add_quota;
if [ $? -gt 0 ] ; then
printf "$SCRIPT:$LINENO: %s\n" "add_quota: FAIL";
exit 192
fi
printf "$SCRIPT:$LINENO: %s\n" "quota not specified: 10000";
else
printf "$SCRIPT:$LINENO: %s\n" "quota disabled: skipping";
fi
sleep 1;
if test "$UNPROC" -ne 15 && test "$UNPROC" -ne 0 ; then
add_nproc;
if [ $? -gt 0 ] ; then
printf "$SCRIPT:$LINENO: %s\n" "add_nproc: FAIL";
exit 192
fi
printf "$SCRIPT:$LINENO: %s\n" "nproc specified: added $UNPROC";
elif [ "$UNPROC" -ne 0 ] ; then
add_nproc;
if [ $? -gt 0 ] ; then
printf "$SCRIPT:$LINENO: %s\n" "add_nproc: FAIL";
exit 192
fi
printf "$SCRIPT:$LINENO: %s\n" "nproc not specified: 15";
else
printf "$SCRIPT:$LINENO: %s\n" "nproc disabled: skipping";
fi
sleep 1;
if test "$ULOGNS" -ne 3 && test "$ULOGNG" -ne 0 ; then
add_logins;
if [ $? -gt 0 ] ; then
printf "$SCRIPT:$LINENO: %s\n" "add_logins: FAIL";
exit 192
fi
printf "$SCRIPT:$LINENO: %s\n" "logins specified: added $ULOGNS"
elif [ "$ULOGNS" -ne 0 ] ; then
add_logins;
if [ $? -gt 0 ] ; then
printf "$SCRIPT:$LINENO: %s\n" "add_logins: FAIL";
exit 192
fi
printf "$SCRIPT:$LINENO: %s\n" "logins not specified: 3";
else
printf "$SCRIPT:$LINENO: %s\n" "logins disabled: skipping";
fi
sleep 1;
if [ "$ULOCL" -eq 0 ] ; then
add_local;
if [ $? -gt 0 ] ; then
printf "$SCRIPT:$LINENO: %s\n" "add_local: FAIL";
exit 192
fi
printf "$SCRIPT:$LINENO: %s\n" "local not specified: added local";
else
printf "$SCRIPT:$LINENO: %s\n" "local specified: skipping";
fi
sleep 1;
if [ "$UCRON" -eq 1 ] ; then
add_cron;
if [ $? -gt 0 ] ; then
printf "$SCRIPT:$LINENO: %s\n" "add_cron: FAIL";
exit 192
fi
printf "$SCRIPT:$LINENO: %s\n" "cron specified: adding cron";
else
printf "$SCRIPT:$LINENO: %s\n" "cron not specified: skipping";
fi
sleep 1;
if [ "$UAT" -gt 0 ] ; then
add_at;
if [ $? -gt 0 ] ; then
printf "$SCRIPT:$LINENO: %s\n" "add_at: FAIL";
exit 192
fi
printf "$SCRIPT:$LINENO: %s\n" "at specified: adding $UAT";
else
printf "$SCRIPT:$LINENO: %s\n" "at not specified: skipping";
fi
sleep 1;
if [ "$UAGE" -eq 1 ] ; then
add_chage;
if [ $? -gt 0 ] ; then
printf "$SCRIPT:$LINENO: %s\n" "add_chage: FAIL";
exit 192
fi
printf "$SCRIPT:$LINENO: %s\n" "chage specified: adding $UAGE";
else
printf "$SCRIPT:$LINENO: %s\n" "chage not specified: skipping";
fi
sleep 1;
if [ "$UCATGR" != "0" ] ; then
add_cat;
if [ $? -gt 0 ] ; then
printf "$SCRIPT:$LINENO: %s\n" "add_cat: FAIL";
exit 192
fi
printf "$SCRIPT:$LINENO: %s\n" "added cat: $UCATGR";
else
add_seuser;
if [ $? -gt 0 ] ; then
printf "$SCRIPT:$LINENO: %s\n" "add_seuser: FAIL";
exit 192
fi
printf "$SCRIPT:$LINENO: %s\n" "added seuser";
fi
# Clean up
exit $EXITSTATUS
#EOF
#TODO: list, remove, modify, loglevels, interactive
# -xv
#
# Name: loginaccounts.sh
# Description: automate login account management
#
# Author: Dominick Grift
# Version: 0.0.3
# Copyright (C) 2008 Dominick Grift
# This program is free software: you can redistribute it and/or modify
# it under the terms of the GNU Affero General Public License as
# published by the Free Software Foundation, either version 3 of the
# License, or (at your option) any later version.
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
# GNU Affero General Public License for more details.
# You should have received a copy of the GNU Affero General Public License
# along with this program. If not, see
# Report undefined variables
# shopt -s -o nounset
# Global declarations
declare -rx SCRIPT=${0##*/}
declare -rx EXITSTATUS=$?
# My global declarations
declare -r OPTSTRING="-h,-L.-P,-A,-C,-f,-a,-i:,-p:,-c:,-g:,-l:,-n:,-c:,-q:,-e:"
declare UCOMMNT=0 # Optional
declare UGRP="realusers,sshusers" # Tunable
declare USERID # Mandatory
declare RESULT # System
declare UPASSWD # Mandatory
declare ULOGNS=3 # Tunable
declare UNPROC=15 # Tunable
declare ULOCL=0 # Optional
declare UCATGR=0 # Optional
declare UFORWRD=0 # optional
declare UQUOT="10000" # Tunable
declare UEXPR=0 # Optional
declare UPOLY=1 # Optional
declare UCRON=0 # Optional
declare UAT=0 # Optional
declare UAGE=1 # Optional
# Sanity checks
# Requires BASH
if test -z "$BASH" ; then
printf "$SCRIPT:$LINENO: %s\n" "Please run this script with the BASH shell" >&2
exit 192
fi
# Test for input
if test -z "$1" ; then
printf "$SCRIPT:$LINENO: %s\n" "Copyright (C) 2008 Dominick Grift"
printf "$SCRIPT:$LINENO: %s\n" ""
printf "$SCRIPT:$LINENO: %s\n" "This program is free software: you can redistribute it and/or modify"
printf "$SCRIPT:$LINENO: %s\n" "it under the terms of the GNU Affero General Public License as"
printf "$SCRIPT:$LINENO: %s\n" "published by the Free Software Foundation, either version 3 of the"
printf "$SCRIPT:$LINENO: %s\n" "License, or (at your option) any later version."
printf "$SCRIPT:$LINENO: %s\n" ""
printf "$SCRIPT:$LINENO: %s\n" "This program is distributed in the hope that it will be useful,"
printf "$SCRIPT:$LINENO: %s\n" "but WITHOUT ANY WARRANTY; without even the implied warranty of"
printf "$SCRIPT:$LINENO: %s\n" "MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the"
printf "$SCRIPT:$LINENO: %s\n" "GNU Affero General Public License for more details."
printf "$SCRIPT:$LINENO: %s\n" ""
printf "$SCRIPT:$LINENO: %s\n" "You should have received a copy of the GNU Affero General Public License"
printf "$SCRIPT:$LINENO: %s\n" "along with this program. If not, see
exit 0
fi
# Test for root
if [ `whoami` != "root" ] ; then
printf "$SCRIPT:$LINENO: %s\n" "DAC: Must be root" >&2
exit 192
fi
# Test for unconfined
if [ `id -Z | awk 'BEGIN { FS=":" } { print $3 }'` != unconfined_t ] ; then
printf "$SCRIPT:$LINENO: %s\n" "MAC: Must be unconfined domain" >&2
exit 192
fi
# Check getopt mode
getopt -T
if [ $? -ne 4 ] ; then
printf "$SCRIPT: %s\n" "Getopt is in compatibility mode" >&2
exit 192
fi
# Test parameters
RESULT='getopt --name "$SCRIPT" --options "$OPTSTRING" --longoptions "help" "identity" "password" "comment" "groups" "logins" "nproc" "local" "range" "forward" "quota" "expire" "poly" "cron" "at" "chage" -- "$@"'
if [ $? -gt 0 ] ; then
exit 192
fi
# Functions
add_user() {
/usr/sbin/useradd "$USERID" 1>&2 >/dev/null;
}
add_user_passwd() {
/bin/echo "$UPASSWD" | /usr/bin/passwd "$USERID" --stdin 1>&2 >/dev/null;
}
add_comment() {
/usr/sbin/usermod -c "$UCOMMNT" "$USERID" 1>&2 >/dev/null;
}
add_expire() {
/usr/sbin/usermod -e "$UEXPR" "$USERID" 1>&2 >/dev/null;
}
add_poly() {
/bin/mkdir /home/"$USERID"/"$USERID".inst && chmod -R 000 /home/"$USERID"/"$USERID".inst 1>&2 >/dev/null;
}
no_poly() {
/bin/sed '/^\/tmp/s/$/\,$USERID/' /etc/security/namespace.conf > tmpfile && /bin/cp tmpfile /etc/security/namespace.conf; /bin/rm tmpfile;
/bin/sed '/^\/var/s/$/\,$USERID/' /etc/security/namespace.conf > tmpfile && /bin/cp tmpfile /etc/security/namespace.conf; /bin/rm tmpfile;
/bin/sed '/^\$HOME/s/$/\,$USERID/' /etc/security/namespace.conf > tmpfile && /bin/cp tmpfile /etc/security/namespace.conf; /bin/rm tmpfile;
}
add_forward() {
/bin/echo """
Match User $USERID
X11Forwarding no
AllowTcpForwarding no""" >> /etc/ssh/sshd_config;
}
add_quota() {
/usr/sbin/setquota -u "$USERID" 0 "$UQUOT" 7500 10000 -a 1>&2 >/dev/null;
}
add_nproc() {
/bin/echo "$USERID hard nproc $UNPROC" >> /etc/security/limits.conf;
}
add_logins() {
/bin/echo "$USERID - maxlogins $ULOGNS" >> /etc/security/limits.conf;
}
add_local() {
/bin/echo "- : $USERID : LOCAL" >> /etc/security/access.conf;
}
add_cron() {
/bin/echo "$USERID" >> /etc/cron.allow;
}
add_at() {
/bin/echo "$USERID" >> /etc/at.allow;
}
add_groups() {
/usr/sbin/usermod -G "$UGRP" "$USERID" 1>&2 >/dev/null;
}
add_cat() {
NEWCAT=:$UCATGR
/usr/sbin/semanage user -a -L s0 -r "s0-s0$NEWCAT" -R user_r -P user "$USERID" 1>&2 >/dev/null;
/usr/sbin/semanage login -a -s "$USERID" -r "s0-s0$NEWCAT" "$USERID" 1>&2 >/dev/null;
}
add_seuser() {
/usr/sbin/semanage user -a -L s0 -r "s0-s0" -R user_r -P user "$USERID" 1>&2 >/dev/null;
/usr/sbin/semanage login -a -s "$USERID" -r "s0-s0" "$USERID" 1>&2 >/dev/null;
}
add_chage() {
/usr/bin/chage -m 7 -M 180 -W 7 "$USERID" 1>&2 >/dev/null;
}
# Main loop
# Replace the parameters with the results of getopt
eval set -- "$RESULT"
# Process the parameters
while [ $# -gt 0 ] ; do
case "$1" in
-h | --help) # Show help
printf "$SCRIPT:$LINENO: %s\n" "Usage: $SCRIPT [options]"
printf "$SCRIPT:$LINENO: %s\n" ""
printf "$SCRIPT:$LINENO: %s\n" " Options:"
printf "$SCRIPT:$LINENO: %s\n" " [-h][--help] | View this help"
printf "$SCRIPT:$LINENO: %s\n" " [-L][--local] | Optional: Disabled by default"
printf "$SCRIPT:$LINENO: %s\n" " [-f][--forward] | Optional: Disabled by default"
printf "$SCRIPT:$LINENO: %s\n" " [-P][--poly] | Optional: Enabled by default"
printf "$SCRIPT:$LINENO: %s\n" " [-C][--cron] | Optional: Disabled by default"
printf "$SCRIPT:$LINENO: %s\n" " [-A][--at] | Optional: Disabled by default"
printf "$SCRIPT:$LINENO: %s\n" " [-a][--chage] | Optional: Enabled by default"
printf "$SCRIPT:$LINENO: %s\n" " [-i][--identity] identity | Mandatory: User name"
printf "$SCRIPT:$LINENO: %s\n" " [-p][--password] password | Mandatory: Strong password"
printf "$SCRIPT:$LINENO: %s\n" " [-c][--comment] comment | Tunable: Defaults to none"
printf "$SCRIPT:$LINENO: %s\n" " [-g][--groups] groups | Tunable: Defaults to realusers,sshusers"
printf "$SCRIPT:$LINENO: %s\n" " [-l][--logins] number of logins | Tunable: Defaults to 3"
printf "$SCRIPT:$LINENO: %s\n" " [-n][--nproc] number of processes| Tunable: Defaults to 15"
printf "$SCRIPT:$LINENO: %s\n" " [-r][--range] range | Optional: Disabled by default"
printf "$SCRIPT:$LINENO: %s\n" " [-q][--quota] number of blocks | Tunable: Defaults to 10000 blocks"
printf "$SCRIPT:$LINENO: %s\n" " [-e][--expire] date | Optional: Disabled by default"
printf "$SCRIPT:$LINENO: %s\n" ""
printf "$SCRIPT:$LINENO: %s\n" " Examples:"
printf "$SCRIPT:$LINENO: %s\n" " $SCRIPT -i john -c \"John Doe\" -p F000_Bar!!1 -r c2,c4 -e 2010-12-15 -C"
exit 0
;;
-i | --identity) shift
if [ $# -eq 0 ] ; then
printf "$SCRIPT:$LINENO: %s\n" "Identity for [-i][--identity] is missing" >&2
exit 192
fi
USERID="$1"
;;
-p | --password) shift
if [ $# -eq 0 ] ; then
printf "$SCRIPT:$LINENO: %s\n" "Password for [-p][--password] is missing" >&2
exit 192
fi
UPASSWD="$1"
;;
-c | --comment) shift
if [ $# -eq 0 ] ; then
printf "$SCRIPT:$LINENO: %s\n" "Comment for [-c][--comment] is missing" >&2
exit 192
fi
UCOMMNT="$1"
;;
-g | --groups) shift
if [ $# -eq 0 ] ; then
printf "$SCRIPT:$LINENO: %s\n" "Groups for [-g][--groups] are missing" >&2
exit 192
fi
UGRP="$1"
;;
-l | --logins) shift
if [ $# -eq 0 ] ; then
printf "$SCRIPT:$LINENO: %s\n" "Number of logins for [-l][--logins] is missing" >&2
exit 192
fi
ULOGNS="$1"
;;
-n | --nproc) shift
if [ $# -eq 0 ] ; then
printf "$SCRIPT:$LINENO: %s\n" "Number of processes for [-n][--nproc] is missing" >&2
exit 192
fi
UNPROC="$1"
;;
-L | --local) shift
ULOCL=1
;;
-P | --poly) shift
UPOLY=0
;;
-r | --range) shift
if [ $# -eq 0 ] ; then
printf "$SCRIPT:$LINENO: %s\n" "Range for [-r][--range] is missing" >&2
exit 192
fi
UCATGR="$1"
;;
-f | --forward) shift
UFORWRD=1
;;
-C | --cron) shift
UCRON=1
;;
-A | --at) shift
UAT=1
;;
-a | --chage) shift
UAGE=0
;;
-q | --quota) shift
if [ $# -eq 0 ] ; then
printf "$SCRIPT:$LINENO: %s\n" "Quota for [-q][--quota] is missing" >&2
exit 192
fi
UQUOT="$1"
;;
-e | --expire) shift
if [ $# -eq 0 ] ; then
printf "$SCRIPT:$LINENO: %s\n" "Expiration date for [-e][--expire] is missing" >&2
exit 192
fi
UEXPR="$1"
;;
esac
shift
done
if [ -z "$USERID" ] ; then
printf "$SCRIPT:$LINENO: %s\n" "Identity missing" >&2
exit 192
fi
if [ -z "$UPASSWD" ] ; then
printf "$SCRIPT:$LINENO: %s\n" "Password missing" >&2
exit 192
fi
# Processing
if test -n "$USERID" ; then
add_user;
if [ $? -gt 0 ] ; then
printf "$SCRIPT:$LINENO: %s\n" "add_user: FAIL";
exit 192
fi
printf "$SCRIPT:$LINENO: %s\n" "added user: $USERID";
else
printf "$SCRIPT:$LINENO: %s\n" "no identity specified: should not be here";
exit 192
fi
sleep 1;
if test -n "$UPASSWD" ; then
add_user_passwd;
if [ $? -gt 0 ] ; then
printf "$SCRIPT:$LINENO: %s\n" "add_passwd: FAIL";
exit 192
fi
printf "$SCRIPT:$LINENO: %s\n" "added passwd: $UPASSWD";
else
printf "$SCRIPT:$LINENO: %s\n" "no password specified: should not be here";
exit 192
fi
sleep 1;
if test "$UCOMMNT" -ne 0 ; then
add_comment;
if [ $? -gt 0 ] ; then
printf "$SCRIPT:$LINENO: %s\n" "add_comment: FAIL";
exit 192
fi
printf "$SCRIPT:$LINENO: %s\n" "added comment: $UCOMMNT";
else
printf "$SCRIPT:$LINENO: %s\n" "no comment specified: skipping";
fi
sleep 1;
if [ "$UGRP" != "realusers,sshusers" ] ; then
add_groups;
if [ $? -gt 0 ] ; then
printf "$SCRIPT:$LINENO: %s\n" "add_groups: FAIL";
exit 192
fi
printf "%s\n" "added groups: $UGRP";
else
add_groups;
if [ $? -gt 0 ] ; then
printf "$SCRIPT:$LINENO: %s\n" "add_groups: FAIL";
exit 192
fi
printf "$SCRIPT:$LINENO: %s\n" "no groups specified: realusers,sshusers";
fi
sleep 1;
if [ "$UEXPR" != "0" ] ; then
add_expire;
if [ $? -gt 0 ] ; then
printf "$SCRIPT:$LINENO: %s\n" "add_expire: FAIL";
exit 192
fi
printf "$SCRIPT:$LINENO: %s\n" "added expire: $UEXPR";
else
printf "$SCRIPT:$LINENO: %s\n" "no expire specified: skipping";
fi
sleep 1;
if [ "$UPOLY" -eq 1 ] ; then
add_poly;
if [ $? -gt 0 ] ; then
printf "$SCRIPT:$LINENO: %s\n" "add_poly: FAIL";
exit 192
fi
printf "$SCRIPT:$LINENO: %s\n" "poly not specified: enabled poly"
else
no_poly;
printf "$SCRIPT:$LINENO: %s\n" "poly specified: disabled poly";
fi
sleep 1;
if [ "$UFORWRD" -lt 1 ] ; then
add_forward;
if [ $? -gt 0 ] ; then
printf "$SCRIPT:$LINENO: %s\n" "add forward: FAIL";
exit 192
fi
printf "$SCRIPT:$LINENO: %s\n" "forward not specified: added forward";
else
printf "$SCRIPT:$LINENO: %s\n" "forward specified: skipping";
fi
sleep 1;
if test "$UQUOT" -ne 10000 && test "$UQUOT" -n 0 ; then
add_quota;
if [ $? -gt 0 ] ; then
printf "$SCRIPT:$LINENO: %s\n" "add_quota: FAIL";
exit 192
fi
printf "$SCRIPT:$LINENO: %s\n" "added quota: $UQUOT"
elif [ "$UQUOT" -ne 0 ] ; then
add_quota;
if [ $? -gt 0 ] ; then
printf "$SCRIPT:$LINENO: %s\n" "add_quota: FAIL";
exit 192
fi
printf "$SCRIPT:$LINENO: %s\n" "quota not specified: 10000";
else
printf "$SCRIPT:$LINENO: %s\n" "quota disabled: skipping";
fi
sleep 1;
if test "$UNPROC" -ne 15 && test "$UNPROC" -ne 0 ; then
add_nproc;
if [ $? -gt 0 ] ; then
printf "$SCRIPT:$LINENO: %s\n" "add_nproc: FAIL";
exit 192
fi
printf "$SCRIPT:$LINENO: %s\n" "nproc specified: added $UNPROC";
elif [ "$UNPROC" -ne 0 ] ; then
add_nproc;
if [ $? -gt 0 ] ; then
printf "$SCRIPT:$LINENO: %s\n" "add_nproc: FAIL";
exit 192
fi
printf "$SCRIPT:$LINENO: %s\n" "nproc not specified: 15";
else
printf "$SCRIPT:$LINENO: %s\n" "nproc disabled: skipping";
fi
sleep 1;
if test "$ULOGNS" -ne 3 && test "$ULOGNG" -ne 0 ; then
add_logins;
if [ $? -gt 0 ] ; then
printf "$SCRIPT:$LINENO: %s\n" "add_logins: FAIL";
exit 192
fi
printf "$SCRIPT:$LINENO: %s\n" "logins specified: added $ULOGNS"
elif [ "$ULOGNS" -ne 0 ] ; then
add_logins;
if [ $? -gt 0 ] ; then
printf "$SCRIPT:$LINENO: %s\n" "add_logins: FAIL";
exit 192
fi
printf "$SCRIPT:$LINENO: %s\n" "logins not specified: 3";
else
printf "$SCRIPT:$LINENO: %s\n" "logins disabled: skipping";
fi
sleep 1;
if [ "$ULOCL" -eq 0 ] ; then
add_local;
if [ $? -gt 0 ] ; then
printf "$SCRIPT:$LINENO: %s\n" "add_local: FAIL";
exit 192
fi
printf "$SCRIPT:$LINENO: %s\n" "local not specified: added local";
else
printf "$SCRIPT:$LINENO: %s\n" "local specified: skipping";
fi
sleep 1;
if [ "$UCRON" -eq 1 ] ; then
add_cron;
if [ $? -gt 0 ] ; then
printf "$SCRIPT:$LINENO: %s\n" "add_cron: FAIL";
exit 192
fi
printf "$SCRIPT:$LINENO: %s\n" "cron specified: adding cron";
else
printf "$SCRIPT:$LINENO: %s\n" "cron not specified: skipping";
fi
sleep 1;
if [ "$UAT" -gt 0 ] ; then
add_at;
if [ $? -gt 0 ] ; then
printf "$SCRIPT:$LINENO: %s\n" "add_at: FAIL";
exit 192
fi
printf "$SCRIPT:$LINENO: %s\n" "at specified: adding $UAT";
else
printf "$SCRIPT:$LINENO: %s\n" "at not specified: skipping";
fi
sleep 1;
if [ "$UAGE" -eq 1 ] ; then
add_chage;
if [ $? -gt 0 ] ; then
printf "$SCRIPT:$LINENO: %s\n" "add_chage: FAIL";
exit 192
fi
printf "$SCRIPT:$LINENO: %s\n" "chage specified: adding $UAGE";
else
printf "$SCRIPT:$LINENO: %s\n" "chage not specified: skipping";
fi
sleep 1;
if [ "$UCATGR" != "0" ] ; then
add_cat;
if [ $? -gt 0 ] ; then
printf "$SCRIPT:$LINENO: %s\n" "add_cat: FAIL";
exit 192
fi
printf "$SCRIPT:$LINENO: %s\n" "added cat: $UCATGR";
else
add_seuser;
if [ $? -gt 0 ] ; then
printf "$SCRIPT:$LINENO: %s\n" "add_seuser: FAIL";
exit 192
fi
printf "$SCRIPT:$LINENO: %s\n" "added seuser";
fi
# Clean up
exit $EXITSTATUS
#EOF
#TODO: list, remove, modify, loglevels, interactive
maandag 21 juli 2008
notes
Explain newrole versus sudo to: transition user domain.
in f10 selinux-policy-targeted newrole is no longer encouraged to be used for domain transitions. in policy mls it is still used (but mls is not common)
sudo allows root privileges without actually knowing the root password.
su with newrole still requires a user to enter a root password to gain root privileges.
not needing a root password anymore is a big advantage!
---
from the wiki:
SELinux and virtualization (relabeling images if images are not in /etc/xen/).
this is not a domain specific issue. customized types. the solution should be man virt_selinux or man xen_selinux like man httpd_selinux. however there is no man xen_selinux yet etc.
this may no longer be an issue in fedora 10 , virt is working on a solution to be implemented in f10
---
make sure to use proper selinux terminology consequent in an effort to keep it simple.
subject object, security context, domain types, file types, port types, security level, categories, domain transition, executable file types, domain, application domain, user domain, init daemon, classes, attributes, scontext, tcontext, access vector cache, type enforcement, multi level security, multi category security.
---
from the wiki:
Mounting:
• Do mount points need to be mnt_t?
boolean mount_any_file. this is also kind of a customized type issue. use semanage boolean -l to list all booleans and their explanation. for example:
/usr/sbin/semanage boolean -l | grep mount
sh-3.2# /usr/sbin/semanage boolean -l | grep mount
allow_mount_anyfile -> off Allow the mount command to mount any directory or file.
xguest_mount_media -> off Allow xguest users to mount removable media
consideration: you should consider to not mention get,setsebool. semanage also provides this functionality. keep it simple
---
from the wiki:
mislabeled files, relabeled but still problems, touch /.autorelabel (Dans journal).
aplain how touch /.autorelabel && reboot relates to fixfiles relabel
---
different policies:
first there was strict and optional mls (for dod). strict was in fedora2. it was introduced too soon. users were too restricted. targeted was introduced to avoid restriction on users.unconfined domain is a domain exempted fro m most selinux policy. unconfined is a property of targeted policy. targeted policy only targets a select group. strict targets everything on a system. targeted plus multi category security (mcs) which is a (poor) implementation of confidentiality(its discretionary users can chcat aslong as they are member of the cat. mcs in policy mls is part of security level. in policy mls, mcs is mandatory.mls is strict plus BLP, plus MCS, plus MLS. strict no longer maintained, merged with targeted. (strict plus unconfined domain) if you remove the unconfined domain then you use what use to be strict. at the moment there are two selinux policy models maintained: policy targeted and policy-mls. mls aims to enforces confidentiality BLP.
SELinux policy and dependencies.
A policy module has 3 files. Here is the explaination of the 3 files.
mydomain.te (.te) (type enforcement file) it has PRIVATE policy for the "mydomain" policy module.
mydomain.if (.if) (interface file) it has PUBLIC policy for the "mydomain" policy module.
mydomain.fc (.fc) (file context file) it has file contexts for the "mydomain" policy module.
The type enforcement file.
This file has private policy. Policy that is, in my example, related to "mydomain"
for example, you might find a rule like this in the mydomain.te file:
apache_read_user_content(mydomain_t)
This policy was provided by apache.if to "mydomain". You can look it up in the apache.if file. It is really a template or interface with rules for how to read apaches user content. We are using (instantiating) that interface that apache policy module provides in it's apache.if file, in our mydomain.te file.
Let us refer to interfaces and templates as blocks of public policy. Public policy blocks should be prefixed by the policy module name of the domain that facilitates it in it's .if (interface file).
for example, just by looking at the following interface call in mydomain.te i know: 1. which module provided the interface 2. where to roughly find it. 3. where to find what policy te interface provides. 4. which domain instantiates the block of public policy:
alsa_read_rw_config(mydomain_t)
1. provided by the alsa policy module.
2. can be found in alsa.if
3. Summary: Read alsa writable config files
allow $1 alsa_etc_rw_t:dir list_dir_perms;
read_files_pattern($1,alsa_etc_rw_t,alsa_etc_rw_t)
read_lnk_files_pattern($1,alsa_etc_rw_t,alsa_etc_rw_t)
4. this policy is instantiated by mydomain_t domain.
So you can easily from looking at a .te file know the modules dependencies by parsing each called interface prefix. as each called interface is prefixed by the domain that made it available in its interface file.
important note regarding public policy.
creating a quick policy module package(.pp) can be very handy for implementing quick policy. but it is also limited.
to compile policy one need selinux-devel. it has development files for each module that is used by the compiler to see if the policy that we want to compile is valid.
when you compile and install a seperate policy package with semodule -i mydomain.pp for example. there will not be a devel package installed.
interfaces files are therefore rendered useless for seperate policy module packages. for the reason that other modules will not be able too instantiate any public policy for that module.
the reason is that when you try to compile your module that has a call to a public policy block of a module that was installed with semodule, the compiler will nnot find that interface/ template in its devel files because non were installed!
This is important to know!
do you want to develop and implement much policy, then do not use policy module packages with semodule but instead integrate your module into the selinux-policy source provided upstream, rebuild it and reinstall it.
by rebuilding selinux-policy, a new selinux-policy-devel package is created. this selinux-policy-devel package DOES include the public policy for the domain that you integrated and thus is usable as opposed to using a .pp with semodule.
http://domg472.blogspot.com/2008/05/how-to-create-integrate-and-rebuild.html
Basic access control models ( DAC , MAC ) ( not so basic MDAC )
explain discretionary
explain the dac model attributes: user group permission bits
explain why dac acl is not sufficient. example privilege escalation
explain the mac model attributes: security context
explain mandatory
explain that MAC is ACL layer on top of the DAC ACL layer
explain Type enforcement
explain Role Based AC
explain Multi Level Security
Explain Multi Category/Compartment Security
compare a selinux system to a submarine with compartments. if one compartment has a leak, the water will be contained to that compartment and will not be able to spread ( escalate) . submarine will not sink
Security context / SELinux attributes
explain the security context tuple and how to read it (explain the fields)
explain user ( which SELinux user (group) created the object? )
explain type is the attribute for type enforcement (TE)
explain role is the attribute for role enforcement (RBAC)
explain security level is the attribute for security level enforcement (MLS)
explain categories/compartments is the attribute for security level enforcement or category/compartment enforcement (MLS or MCS)
Subjects and objects ( processes and "files" )
explain that everything in a system is a object
explain that even subjects in a system are represented as objects in proc mountpoint
explain subjects and objects
explain subjects are processes (ps auxZ)
explain objects are "files" (ls -alZ)
- file objects ( files , lnk files, dirs, fifo files, sock files etc)
- port objects
- interface objects
- node objects
- objects available by other programs ACE access control extension: XACE, sepostgesql, SEDBUS, mscd, etc.
- explain object is a class defined in kernel :process :file :tcp_socket
example of a class: process. example of a class: file
explain domain type is the attribute of a process ( user_t is (user) domain type/attribute of "user"
explain object type is the attribute of a object or "file". do not mistake files with file objects/file types. a "file" is any object
explain that a object type can never be a scontext ( source context ) in a avc denail
explain that processes (subjects) generally operate on files (objects)
explain that processes (subjects) also operate on other processes (subjects) example: process ( sigchld ) if a user processes spawns a program process.
explain that "files" ( objects ) do not operate. they get operated on by subjects ( processes )
explain permissions that define how to operate on subjects and objects ( classes ) are defined in the kernel and are attributes of classes
explain classes and their attributes are static defined in kernel:
- example of a file object class and its attributes:
+ file read
+ dir write
+ lnk_file getattr
- example of a subject class and its attributes:
+ process sigchld
- example of a object available by other programs ACL
+ dbus send_msg
explain that although classes and their attributes are defined in the kernel, that one can assign "types" to subjects and objects, and that one can define policy for these types can interact using the object classes and their attributes supplied by the kernel.
example:
scontext/domain type/subject | tcontext/file type/object | "object" class | "object" permissions/attributes
___________________________________________________________________________________________________________________________
user_t | user_home_t | dir | getattr
httpd_t | httpd_sys_content_ra_t | file | read
user_t | mozilla_t | process | sigchld
user_t | self | process | transition
mozilla_t | httpd_port_t | tcp_socket | connect
unconfined_t | cupsd_t | dbus | send_msg
How to find out if selinux is supported /enabled:
supported?: http://domg444.blogspot.com/2007/11/how-to-determine-if-our-system-supports.html
enabled?: getenforce /selinux/config sestatus
explain selinux framework and selinux policy. explain the selinux framework is responsible for enforcing policy.
explain the access vector cache.
perruse selinux packages ( rpm -ql ) and discuss important locations : /etc/selinux , /selinux
How to disable SELinux: i refer to dwalsh blog. some highlights selinux=0 , enforcing=0, setenforce 0, system-config-selinux, semanage
system-config-selinux is a GUI for semanage. semanage is THE central managing point for SELinux administration:
label file objects ( semanage fcontect -a)
label port objects ( semanage port -a) etc
explain each optipn of semanage and system-config-selinux: label interfaces, set booleans, add , modify, delete selinux user (groups) and SELinux logins.
explain translation ( requires mcstransd )
explain what mcstransd does
explain what restorecond does
explain auditd connection to selinux ( explain ausearch /auctl )
show some pratical examples for managing users. add a unconfined user , add a confined user , add a staff users, assign mcs categories to user (ranges)
create custom selinux user groups
create custom selinux logins
explain booleans
explain customizable types
mention manual pages for targeted daemons.
explain audit2allow
explain audit2why
explain sesearch and how you can use this to make decisions
explain semodule, sestatus , restorecon , semanage, setenforce , getenforce
explain limitations of chcon
explain advantage of chcon
explain chcat
explain selinux-policy-devel ( /usr/share/selinux/devel/Makefile )
show example how to make a custom policy module
explain the limitations of a policy module package
explain the advantages of a policy module package
explain role base access control and derrived types.
explain star and selinux tar support (exmaples)
important: Possible problems caused from running in permissive mode, such as having permissions to mislabel files.
important: Copying Vs moving files.
explain avc denials field by field.
explain advantage and limitation of sealert/setroublehoot and how this relates to audit.
explain file_t, unlabeled_t
explain initrc_t
explain unconfined_t
explain sepolgen and gui
explain why /tmp will not be relabled: http://domg444.blogspot.com/2007/11/why-files-with-incompatible-types-in.html
read selinux by example book
explain the MLS vs TARGETED
explain mcs role in targetted versus mcs role in mls
Subjects and object.
a system is really just files. we call files objects. there are different kind of files. There are devices, ports, interfaces, regular files etc. There are also file that can be executed and that spawn a process. A process is also represented as file in the proc file system. processes are called subjects. There are different kind of processes. like there are different kind of files. for example a user process is spawned from a TTY or PTS. these are also represented on a file system as a file. a user program process is spawned from a application executable file and a init daemon is started from a init script which is also represented as a file on the files system. so you see everything just really is a file on your system and processes spawned of these files. files are objects, process are subjects.
SElinux lets us label every file and thus everything in a system. SElinux provides classes and permissions. a class for a subject is process and a permission could be signal, to signal the process. a class for a object could be file or dir or tcp_socket etc each type of file has a class and each class has a set of permission that one can use when enforcing flexible selinux.
so theres everything(files), files are either files or processes.(objects or subjects) then there are different kind of objects (file objects , port objects), and there are also different kind of subjects.(user domains, application domains etc).
these different files have classes defined in the kernel and each class has its own set of permissions. one can assign types to each file and specify how each of these types may interact with the other types.
a real user logins into the system by executing a terminal. we labeled the terminal file with a type: tty_terminal_exec_type. this is a executable file. it spawns a user process. one must specify in which domain the user process should run. lets call the user process, or as we also call process: domains, user_t.
first we should assign the type to the object. we can use chcon or semanage to assign types to file objects and interface objects and port objects. then we should define the rules so that when the user runs the tty terminal file it transition to a user domain.
this is fiction:
file_type tty_terminal_exec_type; # declare a type for your object
userdomain_transition(user_type,tty_terminal_exec_type) # this macro would suggest that when the object with type tty_terminal_type gets executed, the user process (subject) should transtion to the user_type domain.
now we assigned a user domain type (user_type) to a user process. In SElinux world all access between the types is denied by default. so unless there is policy is specified this user domain will not be able to access any other object other then the tty object it executed to get here. lets give this user domain type access to a file type. file type is a name for a set of different kind of files including a general file and a directory file.
lets give directory ~/test a file type of test_dir_type and a file ~/test/file.txt a file type of test_file_type. we use chcon or semanage to assign the file type to the dir and file. and specify how our user domain type may interact with these file types
the class for our user domain type is process. this is static in the kernel. the classes for a file type are dir for the directory file and file for the regular file. also static in the kernel. permissions specific to the file type class are for examples getattr search read write etc. lets write policy
(me executing the tty_terminal with executable file type tty_terminal_exec_t)
allow me to get attribute of class dir with file type test_dir_t
allow user_type test_dir_type:dir getattr;
allow me to manage class dir with file type test_dir_t
allow user_type test_dir_type:dir manage_dir_perms;
the manage_dir_perms is a macro that represents all permissions needed to manage a dir class.
allow me to read class file with file type test_file_type
allow user_type test_file_type:file read;
now we can manage the dir object with file type test_dir_t and class dir and we (subject with a user domain type) can read the file object with file_type test_file_t and class file
can you imagine the flexibility? can you imagine the ammount of rules? how to keep this managable? answer: macros.
selinux_chk2lst.txt
explain permissive mode and how that relates to selinux=0. permissive logs would be denials, selinux=0 or the option to disable it in /etc/selinux/config will fully disable selinux.
concentrate on semanage. this is the most important tool for users. if a users knows all options in semanage and how/when to apply them then the user knows alot about selinux. maybe treat semanage as an entrypoint.
if a user knows semanage then the user will have no trouble with system_config_selinux. but focus on semanage and not system config selinux (but ofcourse do mention it)
in f10 selinux-policy-targeted newrole is no longer encouraged to be used for domain transitions. in policy mls it is still used (but mls is not common)
sudo allows root privileges without actually knowing the root password.
su with newrole still requires a user to enter a root password to gain root privileges.
not needing a root password anymore is a big advantage!
---
from the wiki:
SELinux and virtualization (relabeling images if images are not in /etc/xen/).
this is not a domain specific issue. customized types. the solution should be man virt_selinux or man xen_selinux like man httpd_selinux. however there is no man xen_selinux yet etc.
this may no longer be an issue in fedora 10 , virt is working on a solution to be implemented in f10
---
make sure to use proper selinux terminology consequent in an effort to keep it simple.
subject object, security context, domain types, file types, port types, security level, categories, domain transition, executable file types, domain, application domain, user domain, init daemon, classes, attributes, scontext, tcontext, access vector cache, type enforcement, multi level security, multi category security.
---
from the wiki:
Mounting:
• Do mount points need to be mnt_t?
boolean mount_any_file. this is also kind of a customized type issue. use semanage boolean -l to list all booleans and their explanation. for example:
/usr/sbin/semanage boolean -l | grep mount
sh-3.2# /usr/sbin/semanage boolean -l | grep mount
allow_mount_anyfile -> off Allow the mount command to mount any directory or file.
xguest_mount_media -> off Allow xguest users to mount removable media
consideration: you should consider to not mention get,setsebool. semanage also provides this functionality. keep it simple
---
from the wiki:
mislabeled files, relabeled but still problems, touch /.autorelabel (Dans journal).
aplain how touch /.autorelabel && reboot relates to fixfiles relabel
---
different policies:
first there was strict and optional mls (for dod). strict was in fedora2. it was introduced too soon. users were too restricted. targeted was introduced to avoid restriction on users.unconfined domain is a domain exempted fro m most selinux policy. unconfined is a property of targeted policy. targeted policy only targets a select group. strict targets everything on a system. targeted plus multi category security (mcs) which is a (poor) implementation of confidentiality(its discretionary users can chcat aslong as they are member of the cat. mcs in policy mls is part of security level. in policy mls, mcs is mandatory.mls is strict plus BLP, plus MCS, plus MLS. strict no longer maintained, merged with targeted. (strict plus unconfined domain) if you remove the unconfined domain then you use what use to be strict. at the moment there are two selinux policy models maintained: policy targeted and policy-mls. mls aims to enforces confidentiality BLP.
SELinux policy and dependencies.
A policy module has 3 files. Here is the explaination of the 3 files.
mydomain.te (.te) (type enforcement file) it has PRIVATE policy for the "mydomain" policy module.
mydomain.if (.if) (interface file) it has PUBLIC policy for the "mydomain" policy module.
mydomain.fc (.fc) (file context file) it has file contexts for the "mydomain" policy module.
The type enforcement file.
This file has private policy. Policy that is, in my example, related to "mydomain"
for example, you might find a rule like this in the mydomain.te file:
apache_read_user_content(mydomain_t)
This policy was provided by apache.if to "mydomain". You can look it up in the apache.if file. It is really a template or interface with rules for how to read apaches user content. We are using (instantiating) that interface that apache policy module provides in it's apache.if file, in our mydomain.te file.
Let us refer to interfaces and templates as blocks of public policy. Public policy blocks should be prefixed by the policy module name of the domain that facilitates it in it's .if (interface file).
for example, just by looking at the following interface call in mydomain.te i know: 1. which module provided the interface 2. where to roughly find it. 3. where to find what policy te interface provides. 4. which domain instantiates the block of public policy:
alsa_read_rw_config(mydomain_t)
1. provided by the alsa policy module.
2. can be found in alsa.if
3. Summary: Read alsa writable config files
allow $1 alsa_etc_rw_t:dir list_dir_perms;
read_files_pattern($1,alsa_etc_rw_t,alsa_etc_rw_t)
read_lnk_files_pattern($1,alsa_etc_rw_t,alsa_etc_rw_t)
4. this policy is instantiated by mydomain_t domain.
So you can easily from looking at a .te file know the modules dependencies by parsing each called interface prefix. as each called interface is prefixed by the domain that made it available in its interface file.
important note regarding public policy.
creating a quick policy module package(.pp) can be very handy for implementing quick policy. but it is also limited.
to compile policy one need selinux-devel. it has development files for each module that is used by the compiler to see if the policy that we want to compile is valid.
when you compile and install a seperate policy package with semodule -i mydomain.pp for example. there will not be a devel package installed.
interfaces files are therefore rendered useless for seperate policy module packages. for the reason that other modules will not be able too instantiate any public policy for that module.
the reason is that when you try to compile your module that has a call to a public policy block of a module that was installed with semodule, the compiler will nnot find that interface/ template in its devel files because non were installed!
This is important to know!
do you want to develop and implement much policy, then do not use policy module packages with semodule but instead integrate your module into the selinux-policy source provided upstream, rebuild it and reinstall it.
by rebuilding selinux-policy, a new selinux-policy-devel package is created. this selinux-policy-devel package DOES include the public policy for the domain that you integrated and thus is usable as opposed to using a .pp with semodule.
http://domg472.blogspot.com/2008/05/how-to-create-integrate-and-rebuild.html
Basic access control models ( DAC , MAC ) ( not so basic MDAC )
explain discretionary
explain the dac model attributes: user group permission bits
explain why dac acl is not sufficient. example privilege escalation
explain the mac model attributes: security context
explain mandatory
explain that MAC is ACL layer on top of the DAC ACL layer
explain Type enforcement
explain Role Based AC
explain Multi Level Security
Explain Multi Category/Compartment Security
compare a selinux system to a submarine with compartments. if one compartment has a leak, the water will be contained to that compartment and will not be able to spread ( escalate) . submarine will not sink
Security context / SELinux attributes
explain the security context tuple and how to read it (explain the fields)
explain user ( which SELinux user (group) created the object? )
explain type is the attribute for type enforcement (TE)
explain role is the attribute for role enforcement (RBAC)
explain security level is the attribute for security level enforcement (MLS)
explain categories/compartments is the attribute for security level enforcement or category/compartment enforcement (MLS or MCS)
Subjects and objects ( processes and "files" )
explain that everything in a system is a object
explain that even subjects in a system are represented as objects in proc mountpoint
explain subjects and objects
explain subjects are processes (ps auxZ)
explain objects are "files" (ls -alZ)
- file objects ( files , lnk files, dirs, fifo files, sock files etc)
- port objects
- interface objects
- node objects
- objects available by other programs ACE access control extension: XACE, sepostgesql, SEDBUS, mscd, etc.
- explain object is a class defined in kernel :process :file :tcp_socket
example of a class: process. example of a class: file
explain domain type is the attribute of a process ( user_t is (user) domain type/attribute of "user"
explain object type is the attribute of a object or "file". do not mistake files with file objects/file types. a "file" is any object
explain that a object type can never be a scontext ( source context ) in a avc denail
explain that processes (subjects) generally operate on files (objects)
explain that processes (subjects) also operate on other processes (subjects) example: process ( sigchld ) if a user processes spawns a program process.
explain that "files" ( objects ) do not operate. they get operated on by subjects ( processes )
explain permissions that define how to operate on subjects and objects ( classes ) are defined in the kernel and are attributes of classes
explain classes and their attributes are static defined in kernel:
- example of a file object class and its attributes:
+ file read
+ dir write
+ lnk_file getattr
- example of a subject class and its attributes:
+ process sigchld
- example of a object available by other programs ACL
+ dbus send_msg
explain that although classes and their attributes are defined in the kernel, that one can assign "types" to subjects and objects, and that one can define policy for these types can interact using the object classes and their attributes supplied by the kernel.
example:
scontext/domain type/subject | tcontext/file type/object | "object" class | "object" permissions/attributes
___________________________________________________________________________________________________________________________
user_t | user_home_t | dir | getattr
httpd_t | httpd_sys_content_ra_t | file | read
user_t | mozilla_t | process | sigchld
user_t | self | process | transition
mozilla_t | httpd_port_t | tcp_socket | connect
unconfined_t | cupsd_t | dbus | send_msg
How to find out if selinux is supported /enabled:
supported?: http://domg444.blogspot.com/2007/11/how-to-determine-if-our-system-supports.html
enabled?: getenforce /selinux/config sestatus
explain selinux framework and selinux policy. explain the selinux framework is responsible for enforcing policy.
explain the access vector cache.
perruse selinux packages ( rpm -ql ) and discuss important locations : /etc/selinux , /selinux
How to disable SELinux: i refer to dwalsh blog. some highlights selinux=0 , enforcing=0, setenforce 0, system-config-selinux, semanage
system-config-selinux is a GUI for semanage. semanage is THE central managing point for SELinux administration:
label file objects ( semanage fcontect -a)
label port objects ( semanage port -a) etc
explain each optipn of semanage and system-config-selinux: label interfaces, set booleans, add , modify, delete selinux user (groups) and SELinux logins.
explain translation ( requires mcstransd )
explain what mcstransd does
explain what restorecond does
explain auditd connection to selinux ( explain ausearch /auctl )
show some pratical examples for managing users. add a unconfined user , add a confined user , add a staff users, assign mcs categories to user (ranges)
create custom selinux user groups
create custom selinux logins
explain booleans
explain customizable types
mention manual pages for targeted daemons.
explain audit2allow
explain audit2why
explain sesearch and how you can use this to make decisions
explain semodule, sestatus , restorecon , semanage, setenforce , getenforce
explain limitations of chcon
explain advantage of chcon
explain chcat
explain selinux-policy-devel ( /usr/share/selinux/devel/Makefile )
show example how to make a custom policy module
explain the limitations of a policy module package
explain the advantages of a policy module package
explain role base access control and derrived types.
explain star and selinux tar support (exmaples)
important: Possible problems caused from running in permissive mode, such as having permissions to mislabel files.
important: Copying Vs moving files.
explain avc denials field by field.
explain advantage and limitation of sealert/setroublehoot and how this relates to audit.
explain file_t, unlabeled_t
explain initrc_t
explain unconfined_t
explain sepolgen and gui
explain why /tmp will not be relabled: http://domg444.blogspot.com/2007/11/why-files-with-incompatible-types-in.html
read selinux by example book
explain the MLS vs TARGETED
explain mcs role in targetted versus mcs role in mls
Subjects and object.
a system is really just files. we call files objects. there are different kind of files. There are devices, ports, interfaces, regular files etc. There are also file that can be executed and that spawn a process. A process is also represented as file in the proc file system. processes are called subjects. There are different kind of processes. like there are different kind of files. for example a user process is spawned from a TTY or PTS. these are also represented on a file system as a file. a user program process is spawned from a application executable file and a init daemon is started from a init script which is also represented as a file on the files system. so you see everything just really is a file on your system and processes spawned of these files. files are objects, process are subjects.
SElinux lets us label every file and thus everything in a system. SElinux provides classes and permissions. a class for a subject is process and a permission could be signal, to signal the process. a class for a object could be file or dir or tcp_socket etc each type of file has a class and each class has a set of permission that one can use when enforcing flexible selinux.
so theres everything(files), files are either files or processes.(objects or subjects) then there are different kind of objects (file objects , port objects), and there are also different kind of subjects.(user domains, application domains etc).
these different files have classes defined in the kernel and each class has its own set of permissions. one can assign types to each file and specify how each of these types may interact with the other types.
a real user logins into the system by executing a terminal. we labeled the terminal file with a type: tty_terminal_exec_type. this is a executable file. it spawns a user process. one must specify in which domain the user process should run. lets call the user process, or as we also call process: domains, user_t.
first we should assign the type to the object. we can use chcon or semanage to assign types to file objects and interface objects and port objects. then we should define the rules so that when the user runs the tty terminal file it transition to a user domain.
this is fiction:
file_type tty_terminal_exec_type; # declare a type for your object
userdomain_transition(user_type,tty_terminal_exec_type) # this macro would suggest that when the object with type tty_terminal_type gets executed, the user process (subject) should transtion to the user_type domain.
now we assigned a user domain type (user_type) to a user process. In SElinux world all access between the types is denied by default. so unless there is policy is specified this user domain will not be able to access any other object other then the tty object it executed to get here. lets give this user domain type access to a file type. file type is a name for a set of different kind of files including a general file and a directory file.
lets give directory ~/test a file type of test_dir_type and a file ~/test/file.txt a file type of test_file_type. we use chcon or semanage to assign the file type to the dir and file. and specify how our user domain type may interact with these file types
the class for our user domain type is process. this is static in the kernel. the classes for a file type are dir for the directory file and file for the regular file. also static in the kernel. permissions specific to the file type class are for examples getattr search read write etc. lets write policy
(me executing the tty_terminal with executable file type tty_terminal_exec_t)
allow me to get attribute of class dir with file type test_dir_t
allow user_type test_dir_type:dir getattr;
allow me to manage class dir with file type test_dir_t
allow user_type test_dir_type:dir manage_dir_perms;
the manage_dir_perms is a macro that represents all permissions needed to manage a dir class.
allow me to read class file with file type test_file_type
allow user_type test_file_type:file read;
now we can manage the dir object with file type test_dir_t and class dir and we (subject with a user domain type) can read the file object with file_type test_file_t and class file
can you imagine the flexibility? can you imagine the ammount of rules? how to keep this managable? answer: macros.
selinux_chk2lst.txt
explain permissive mode and how that relates to selinux=0. permissive logs would be denials, selinux=0 or the option to disable it in /etc/selinux/config will fully disable selinux.
concentrate on semanage. this is the most important tool for users. if a users knows all options in semanage and how/when to apply them then the user knows alot about selinux. maybe treat semanage as an entrypoint.
if a user knows semanage then the user will have no trouble with system_config_selinux. but focus on semanage and not system config selinux (but ofcourse do mention it)
maandag 7 juli 2008
Checklist for adding login accounts
Managing login accounts is quite complex nowadays. I decided to make a checklist.
User, only remote access, expires, password aging, restrict openssh, poly-instantiation, no su (%wheel) , no sudo, no exec user content, quota, login limits, nproc limits, mcs categories. no cron (cron.allow), no at (at.allow).
1. Add a login account
/usr/sbin/useradd -c "Full name" -e 2008-12-31 -G realusers,sshusers -K PASS_MAX_DAYS=180 -K PASS_MIN_DAYS=7 -K PASS_MIN_LEN=8 -K PASS_WARN_AGE=7 -p 'password as returned by crypt (3)' 'user_name'
2. Disable perrmissions to execute user content (one time)
/usr/sbin/setsebool -P allow_user_exec_content off
3. Enable poly-instantiation
/usr/sbin/setsebool -P allow_polyinstantiation on
mkdir /home/'user_name'/'user_name'.inst
chmod -R 000 /home/'user_name'/'user_name'.inst
4. Deny local access
echo "- : 'user_name' : LOCAL" >> /etc/security/access.conf
5. set limits
echo "'user_name' - nlogins 3" >> /etc/security/limits.conf
echo "'user_name' hard nprocs 15" >> /etc/security/limits.conf
6. Restrict ssh
echo """Match User 'user_name'
X11Forwarding no
AllowTcpForwarding no""" >> /etc/ssh/ssh_config
7. Assign selinux usergroup,domain and categories
/usr/sbin/semanage user -a -L s0 -r "s0-s0:c4" -R user_r -P user 'user_name'
/use/sbin/semanage login -a -s 'user_name' -r "s0-s0:c4" 'user_name'
cp /etc/selinux/targeted/contexts/users/user_u /etc/selinux/targeted/contexts/users/'user_name'
8. User quota
/usr/sbin/setquota -r -u 'user _name' 7500 10000 7500 10000 -a
User, only remote access, expires, password aging, restrict openssh, poly-instantiation, no su (%wheel) , no sudo, no exec user content, quota, login limits, nproc limits, mcs categories. no cron (cron.allow), no at (at.allow).
1. Add a login account
/usr/sbin/useradd -c "Full name" -e 2008-12-31 -G realusers,sshusers -K PASS_MAX_DAYS=180 -K PASS_MIN_DAYS=7 -K PASS_MIN_LEN=8 -K PASS_WARN_AGE=7 -p 'password as returned by crypt (3)' 'user_name'
2. Disable perrmissions to execute user content (one time)
/usr/sbin/setsebool -P allow_user_exec_content off
3. Enable poly-instantiation
/usr/sbin/setsebool -P allow_polyinstantiation on
mkdir /home/'user_name'/'user_name'.inst
chmod -R 000 /home/'user_name'/'user_name'.inst
4. Deny local access
echo "- : 'user_name' : LOCAL" >> /etc/security/access.conf
5. set limits
echo "'user_name' - nlogins 3" >> /etc/security/limits.conf
echo "'user_name' hard nprocs 15" >> /etc/security/limits.conf
6. Restrict ssh
echo """Match User 'user_name'
X11Forwarding no
AllowTcpForwarding no""" >> /etc/ssh/ssh_config
7. Assign selinux usergroup,domain and categories
/usr/sbin/semanage user -a -L s0 -r "s0-s0:c4" -R user_r -P user 'user_name'
/use/sbin/semanage login -a -s 'user_name' -r "s0-s0:c4" 'user_name'
cp /etc/selinux/targeted/contexts/users/user_u /etc/selinux/targeted/contexts/users/'user_name'
8. User quota
/usr/sbin/setquota -r -u 'user _name' 7500 10000 7500 10000 -a
donderdag 15 mei 2008
How to create, integrate and rebuild SELinux policy for Fedora 9 using Eclipse-Slide and rpmdevtools
In this example i am going to show you how you can write, integrate and rebuild SELinux policy modules for Fedora 9 using Eclipse-Slide and RPMdevtools.
I will create a SELinux policy module for the irssi user application and i will integrate this new policy module into the main Fedora selinux-policy with RPM devtools.
What i need:
yum install rpmdevtools selinux-policy-devel eclipse-slide
Chapter 1. Preparing the source:
First we should determine which selinux policy we have installed so that we can go find and download the corresponding selinux-policy source rpm.
It is determined that the source rpm that i need is not available on the main mirrors and therefore i will try to find it on koji.fedoraproject.org/koji.
I will download the source rpm to my default Download location and extract the package simple by alter-click ing it and chooce extract here from the menu.
Once the source rpm is extracted, a new folder appears with its contents. I am going to copy the included serefpolicy-3.3.1.tgz plus policy-20071130.patch to my desktop. After that i will extract the serefpolicy-3..3.1.tgz located on my desktop and apply the patch thats located on my desktop as well.
At this point the folder serefpolicy-3.3.1 on my desktop represents the prepared source for the binary policy that is installed on my system.
Chapter 2. Loading source policy into a Eclipse-Slide project:
Now i am ready to load the prepared source policy into the Eclipse-Slide IDE. I do this by starting Eclipse, creating a new Slide project and loading the prepared serefpolicy-3.3.1 folder into my new Slide project.
Once the new project is loaded i will attempt to build the project. Note that Eclipse has a settings enabled that will cause your project to be auto compiled by default. This can be an annoyance and so i opt to disable this and build the project manually. Also not that building this project will likely fail. However even so we will still have access to some of the templates and features.
Once the attempt to compile our newly project has finished you will notice that the right hand filter browser is now somewhat populated. This window will assist me with quick navigation in the vast area of interfaces and templates. The left hand window has a project browser which gives me a good oversight of my project. The window below has a few tabs, of which i find the declaration tab very helpfull. The status tab will display any errors or warnings that occoured during compilation. The main window in the middle of the screen i will use to write policy.
Chapter 3. Integrating a new policy module into our Eclipse-Slide project:
Now its time to actually integrate a new policy module into the current project.
I choose the irssi application. This is application is started by users and therefore belongs in the apps subsection of the modules location in our project.
Once you finish the new Slide module wizard, a new workspace is presented with access to your newly create module in the main window in the middle of the screen. Notice hat a module is built out of 3 seperate files which you can access by clicking the corresponding tab in the lower end of the main window in the moddle of the screen.
Chapter 4. Installing and perusing Irssi application:
Since we are going to integrate policy for Irssi, we should install this package by running: yum install irssi. Once this package is installed we can query information about this package. We want to find out to which files irssi application needs to write or which objects Irssi must execute. In this case irssi also has a configuration file /etc/irssi.config that is of particular interest to us.
Chapter 5. About policy modules:
Before i start to write policy i want to explain something. Since Irssi is a user application, it is expected that users (or as wel call them userdomains) have to interact with it. The SELinux world can have infinite userdomains, and policy is based on which user domain interacts with the irssi application domain.
You can imagine how much maintenance work it would take for us to keep our irssi policy up-to-date for any (new) selinux userdomains that may come or go.
It would require very many rules just to differentiate between users. This is why templates and in particular the per_role_template was invented. This template can be invokes for each userdomain.
User information is replaced by variables which are instantiated when the user domain calls the template. This mean that i can use one piece of policy for any user domains that may call it. This saves much maintenance work but also saves us from a huge pile of policy. These templates are hosted by the domain in the interface file in the module. This file is used by domains to host policy. Other domains have easy access to theres interfaces and templates to interact with the domain that hosts the interfaces or templates.
The first step for me to take is to declare any non-user specific types. We know that irssi has an executable in /usr/bin/irssi and we have to declare a type for this excutable: irssi_exec_t.
We also know that irssi owns a file in /etc/irssi.conf, and we should declare a type for this config file in etc as well: irssi_etc_t.
We do this in the irssi.te file. This file has local policy regarding to irssi. The .te file in a module has a few parts: first we declare the policy_module, than we declare any types, booleans and others. and than we call interfaces in other domains and specificy local policy.
Policy that is user domain specific does not belong in a .te file as this policy is called by the user domain and thus should be hosted in the .if file by our domain. More about the .if file later.
So now we have to declare a tpye for irssi_exec_t and irssi_etc_t in irssi.te file in out module
So now we have those two types declared and now i have to make sure that these objects that we declared types for get labelled (/usr/bin/irssi and /etc/irssi.conf) This is done in the .fc file
At this point all out non-user domain specific types are declared and we have taken care of those objects file labelling via the file context file in our module.
Chapter 6. User domain specific policy in modules interface file:
Now we are ready for the part of the module that is called by the userdomains that want to execute irssi. This part is done in the interface file of the module. policy in this file is accessible by domains that call it.
Here is how this works: user domains can call irssi per_role_template so that they can run irssi in its application domain. user domains are expected to call this template in their local policy (.te file): irssi_per_role_template(myuser, myuser_t, myuser_r)
Above you see an example of an empty per_role_template in the irssi.if file in the module. Interfaces and templated are headed by XML comments. These comments can be read by other domains. Other domains that want to interact with out application domain needs this info to be able to calls these templates in a correct manner. This particular template takes 3 directions. userdomain prefix, user domain, and role.
And so if a user domain called myuser wants to run our application domain (in its domain) than that user domain will have to call our per_role_template in its own local policy.
My next step is to declare the remaining user domain specific types. such as the type for the application domain and the type of our application domains objects in the user space.
After i declared those types i will also have to manage object labeling to the remaining declared type for irssi owned objects in the user space.
Now were done with the .fc file
If you remember , we have declared two non user domain specific types in our irssi.te file: irrsi_exec_t and irssi_etc_t. These types are locally declared however, user domains that call the irssi_per_role_template also need access to these types, and since other domains cannot access our local policy (.te) we hav to include or require those types in our irssi_per_role_template in our .if file so that other domains can also interact with these types.
Please note that there is a small syntax error in the picture above. See if you can find what it is. I will at the end of this article show the correction.
Next we have to make some more decisions. We can decide to let any (user)domain automatic transition to the irssi application domain once the user executes the irssi executable or we can decide that the source domain executes irssi in its own domain instead.
I have chosen for an option where we make the above decision tunable by way of a boolean. The result is that by default domains will not transition to the irssi app domain unless a boolean for that particular domain is set.
That boolean is called irssi_confine_$1, where $1 stands for the user domain prefix. The administrator can set a boolean for the particular user domain if he want that domain to run in the irssi application domain.
First we declare our userdomain specific boolean in the declaration section of our irssi_per_role template and in the local policy bit of our template we write policy for this tunable.
Now that we have declared a local boolean we can decide to make some other possibilities optional. For example, maybe we want to enable optional support for NFS or SAMBA home directories. Since these are global booleans, we do not have to declare these booleans but we jut have to write policy for them.
Note that i also added the fs_search_auto_mountpoints() interface so that we can also always search those locations. The contents of this interfaces can easely be referenced to the filesystem module interface file or you can view its contexts by simply selecting the entry and view its declarations in the declaration tab on the lower window (which incidentally is collapsed in the example above.)
New Chapter. Networking:
Irssi connect to a irc server on usually port 6667. This port is already declared as port ircd_port_t in refpolicy and so we can use that policy to let irssi connect to irc servers. however we should declare a network port range for Irssi IRC DCC server facility. We declare a port ircdcc_port_t for tcp 4990-5000. Irssi will use that as its ports for a DCC server or in a single instance mode also for connecting to DCC ports. In case we are not hosting but downloading from another DCC server.
Now that we have declared irssi's DCC server port range we should also set up the rest of irssi networking policy. We simply add a interface to allow connect and send and receive irc client packets from the ircd_port_t port. Plus some other corenetwork module interfaces that are used as defaults.
Please note again that you can inspect what those blue lines really mean in terms of policy if you select it and view its contents in the declaration window (which is collapsable in the lower end of the window.)
Next it is decision making time again. also lets first recap: by default users do not transition to the irssi domain. We choose to make this decision tunable by boolean. If this bool is set than the user runs irssi in its domain. As it stands now irssi may only connect to ports with type irc_port_t which is tcp 6667. irssi will not be able to connect to any other ports. Also the irc_dcc_t port we declared for irssi DCC SERVER is not yet allowed.
We can decide to make this bit tunable or default behaviour. In this example i chose to make iRC DCC tunable and disabled by default unless set (least privilege model), and so we have to create a tunable_policy block again to allow irssi either connect or bind to its dcc port range (tcp 4990-5000)
But since this is a local (but not user domain specific) boolean and not a global boolean, we will have to declare this boolean in the irssi.te file of our module.
The final tunable option we are going to implement is to facilitate mass hosting of irssi. if you want to host multiple instances of irssi and allow those instances to bind and connect to any unreserved ports than you can set the irssi_unreserved_network boolean. this boolean will require all other booleans to be set as well for optimal performance. This scenario is for instances where you may have a shell server that hosts irssi on a machine in the dmz.
So again theres four modes: 1. Disabled unless enabled. 2. Strict (can only connect to port 6667) 3. Single instance mode( can connect to 6667 and connect and bind to 4990-5000) and mass hosting mode ( can connect and bind to any unreserved port plus at of the above)
And ofcourse since this is a local (but not a user domain specific) boolean we will have to also declare this boolean in the irssi.te file in our module.
This next part goes into local* policy that defines how our domain may interact. This is usually the first piece of policy in the local policy block of your module and in this case it is user domain specific and thus should this be in the interface file irssi.if.
This piece of policy i split into 3 parts, Part 1 is policy that governs how our domain can interact with its own process (allow $1_irssi_t self). Part 2 is policy that governs how user domains may interact with the application domain e.g. allow $2 $1_irssi_t. Part 3 is policy that governs how our application domain may interact with the userdomain or allow $1_irssi_t $2)
Now i will deal with our domains objects and how our domain can interact with these objects. First you may remember that we declared a type irssi_etc_t in our irssi.te file. This is a global configuration file that irssi should be able to read,.and so we should give our domain access to search /etc, and we should allow our domain read and get attribute access to files with type irssi_etc_t. This will allow irssi to read the global config file.
Next we must ensure that irssi can manage its userdomain specific objects in the user space. We must ensure that the userdomain can also manage irssi objects in the user home location.
Third we should ensure that the userdomain is able to relabel irssi domain objects in his or her home dir. So that a user can move objects in and out of the irssi domain in his or her home location.
Most of our policy is done now. There are some interfaces that we have to call in other domains. One particular issue is that the userdomain should be able to read the application domains process. This is for using ps auxZ , top and etcetera.
Also note the optional_policy block for nis_use_ypbind. The optional policy block means that the policy is only enabled when NIS is available. This option was added to add NIS support to our module.
Done! lets clean up the project
Now i have to copy my project to my desktop and archive it with exactly the same name as the serepolicy-3.3.1.tgz we extracted and prepared earlier.
Next we should create our personal rpmbuild root
In this part we are going to copy the contents of the folder that we have extracted from our source rpm in our Download location to the newly created SOURCES location in our ~/rpmbuild root.
we will remove the copied *.patch and serefpolicy-3.3.1.tgz from our ~/rpmbuild/SOURCES location and copy the selinux-policy.spec that is is also located there to ~/rpmbuild/SPECS/.
Next we will copy our modified serefpolicy-3.3.1.tgz from our desktop to the ~/.rpmbuild/SOURCES/ location.
Now we should edit our spec file located in ~/rpmbuild/SPECS/selinux-policy-spec. We have to bump up the version number to avoid difficulties. We also have to comment out any patch entries (this is because we already applied the included patches manually in the beginning of our exercise.)
Finally we should add our new module to the modules-targeted.conf file in ~/rpmbuild/SOURCES/ if we want our module to be active in the selinux-policy-targeted package.
Now we can execute rpmbuild -ba ~/rpmbuild/SPECS/selinux-policy.spec and let her rip.
If all (would) go well than you'd get your freshly brewed set of rpms.
But all did not went go well in this example as i made a mistake. The image below shows my mistake corrected. If you have any questions or comments please ping me at #fedora-selinux on freenode
You can find a copy of my irssi policy here http://pastebin.ca/768256?srch=irssi_exec_t it also includes policy for eggdrop and manual pages but it may need some work.
I will create a SELinux policy module for the irssi user application and i will integrate this new policy module into the main Fedora selinux-policy with RPM devtools.
What i need:
yum install rpmdevtools selinux-policy-devel eclipse-slide
Chapter 1. Preparing the source:
First we should determine which selinux policy we have installed so that we can go find and download the corresponding selinux-policy source rpm.
It is determined that the source rpm that i need is not available on the main mirrors and therefore i will try to find it on koji.fedoraproject.org/koji.
I will download the source rpm to my default Download location and extract the package simple by alter-click ing it and chooce extract here from the menu.
Once the source rpm is extracted, a new folder appears with its contents. I am going to copy the included serefpolicy-3.3.1.tgz plus policy-20071130.patch to my desktop. After that i will extract the serefpolicy-3..3.1.tgz located on my desktop and apply the patch thats located on my desktop as well.
At this point the folder serefpolicy-3.3.1 on my desktop represents the prepared source for the binary policy that is installed on my system.
Chapter 2. Loading source policy into a Eclipse-Slide project:
Now i am ready to load the prepared source policy into the Eclipse-Slide IDE. I do this by starting Eclipse, creating a new Slide project and loading the prepared serefpolicy-3.3.1 folder into my new Slide project.
Once the new project is loaded i will attempt to build the project. Note that Eclipse has a settings enabled that will cause your project to be auto compiled by default. This can be an annoyance and so i opt to disable this and build the project manually. Also not that building this project will likely fail. However even so we will still have access to some of the templates and features.
Once the attempt to compile our newly project has finished you will notice that the right hand filter browser is now somewhat populated. This window will assist me with quick navigation in the vast area of interfaces and templates. The left hand window has a project browser which gives me a good oversight of my project. The window below has a few tabs, of which i find the declaration tab very helpfull. The status tab will display any errors or warnings that occoured during compilation. The main window in the middle of the screen i will use to write policy.
Chapter 3. Integrating a new policy module into our Eclipse-Slide project:
Now its time to actually integrate a new policy module into the current project.
I choose the irssi application. This is application is started by users and therefore belongs in the apps subsection of the modules location in our project.
Once you finish the new Slide module wizard, a new workspace is presented with access to your newly create module in the main window in the middle of the screen. Notice hat a module is built out of 3 seperate files which you can access by clicking the corresponding tab in the lower end of the main window in the moddle of the screen.
Chapter 4. Installing and perusing Irssi application:
Since we are going to integrate policy for Irssi, we should install this package by running: yum install irssi. Once this package is installed we can query information about this package. We want to find out to which files irssi application needs to write or which objects Irssi must execute. In this case irssi also has a configuration file /etc/irssi.config that is of particular interest to us.
Chapter 5. About policy modules:Before i start to write policy i want to explain something. Since Irssi is a user application, it is expected that users (or as wel call them userdomains) have to interact with it. The SELinux world can have infinite userdomains, and policy is based on which user domain interacts with the irssi application domain.
You can imagine how much maintenance work it would take for us to keep our irssi policy up-to-date for any (new) selinux userdomains that may come or go.
It would require very many rules just to differentiate between users. This is why templates and in particular the per_role_template was invented. This template can be invokes for each userdomain.
User information is replaced by variables which are instantiated when the user domain calls the template. This mean that i can use one piece of policy for any user domains that may call it. This saves much maintenance work but also saves us from a huge pile of policy. These templates are hosted by the domain in the interface file in the module. This file is used by domains to host policy. Other domains have easy access to theres interfaces and templates to interact with the domain that hosts the interfaces or templates.
The first step for me to take is to declare any non-user specific types. We know that irssi has an executable in /usr/bin/irssi and we have to declare a type for this excutable: irssi_exec_t.
We also know that irssi owns a file in /etc/irssi.conf, and we should declare a type for this config file in etc as well: irssi_etc_t.
We do this in the irssi.te file. This file has local policy regarding to irssi. The .te file in a module has a few parts: first we declare the policy_module, than we declare any types, booleans and others. and than we call interfaces in other domains and specificy local policy.
Policy that is user domain specific does not belong in a .te file as this policy is called by the user domain and thus should be hosted in the .if file by our domain. More about the .if file later.
So now we have to declare a tpye for irssi_exec_t and irssi_etc_t in irssi.te file in out module
So now we have those two types declared and now i have to make sure that these objects that we declared types for get labelled (/usr/bin/irssi and /etc/irssi.conf) This is done in the .fc file
At this point all out non-user domain specific types are declared and we have taken care of those objects file labelling via the file context file in our module.
Chapter 6. User domain specific policy in modules interface file:
Now we are ready for the part of the module that is called by the userdomains that want to execute irssi. This part is done in the interface file of the module. policy in this file is accessible by domains that call it.
Here is how this works: user domains can call irssi per_role_template so that they can run irssi in its application domain. user domains are expected to call this template in their local policy (.te file): irssi_per_role_template(myuser, myuser_t, myuser_r)
Above you see an example of an empty per_role_template in the irssi.if file in the module. Interfaces and templated are headed by XML comments. These comments can be read by other domains. Other domains that want to interact with out application domain needs this info to be able to calls these templates in a correct manner. This particular template takes 3 directions. userdomain prefix, user domain, and role.And so if a user domain called myuser wants to run our application domain (in its domain) than that user domain will have to call our per_role_template in its own local policy.
My next step is to declare the remaining user domain specific types. such as the type for the application domain and the type of our application domains objects in the user space.
After i declared those types i will also have to manage object labeling to the remaining declared type for irssi owned objects in the user space.
Now were done with the .fc file
If you remember , we have declared two non user domain specific types in our irssi.te file: irrsi_exec_t and irssi_etc_t. These types are locally declared however, user domains that call the irssi_per_role_template also need access to these types, and since other domains cannot access our local policy (.te) we hav to include or require those types in our irssi_per_role_template in our .if file so that other domains can also interact with these types.
Please note that there is a small syntax error in the picture above. See if you can find what it is. I will at the end of this article show the correction.Next we have to make some more decisions. We can decide to let any (user)domain automatic transition to the irssi application domain once the user executes the irssi executable or we can decide that the source domain executes irssi in its own domain instead.
I have chosen for an option where we make the above decision tunable by way of a boolean. The result is that by default domains will not transition to the irssi app domain unless a boolean for that particular domain is set.
That boolean is called irssi_confine_$1, where $1 stands for the user domain prefix. The administrator can set a boolean for the particular user domain if he want that domain to run in the irssi application domain.
First we declare our userdomain specific boolean in the declaration section of our irssi_per_role template and in the local policy bit of our template we write policy for this tunable.
Now that we have declared a local boolean we can decide to make some other possibilities optional. For example, maybe we want to enable optional support for NFS or SAMBA home directories. Since these are global booleans, we do not have to declare these booleans but we jut have to write policy for them.
Note that i also added the fs_search_auto_mountpoints() interface so that we can also always search those locations. The contents of this interfaces can easely be referenced to the filesystem module interface file or you can view its contexts by simply selecting the entry and view its declarations in the declaration tab on the lower window (which incidentally is collapsed in the example above.)New Chapter. Networking:
Irssi connect to a irc server on usually port 6667. This port is already declared as port ircd_port_t in refpolicy and so we can use that policy to let irssi connect to irc servers. however we should declare a network port range for Irssi IRC DCC server facility. We declare a port ircdcc_port_t for tcp 4990-5000. Irssi will use that as its ports for a DCC server or in a single instance mode also for connecting to DCC ports. In case we are not hosting but downloading from another DCC server.
Now that we have declared irssi's DCC server port range we should also set up the rest of irssi networking policy. We simply add a interface to allow connect and send and receive irc client packets from the ircd_port_t port. Plus some other corenetwork module interfaces that are used as defaults.
Please note again that you can inspect what those blue lines really mean in terms of policy if you select it and view its contents in the declaration window (which is collapsable in the lower end of the window.)Next it is decision making time again. also lets first recap: by default users do not transition to the irssi domain. We choose to make this decision tunable by boolean. If this bool is set than the user runs irssi in its domain. As it stands now irssi may only connect to ports with type irc_port_t which is tcp 6667. irssi will not be able to connect to any other ports. Also the irc_dcc_t port we declared for irssi DCC SERVER is not yet allowed.
We can decide to make this bit tunable or default behaviour. In this example i chose to make iRC DCC tunable and disabled by default unless set (least privilege model), and so we have to create a tunable_policy block again to allow irssi either connect or bind to its dcc port range (tcp 4990-5000)
But since this is a local (but not user domain specific) boolean and not a global boolean, we will have to declare this boolean in the irssi.te file of our module.
The final tunable option we are going to implement is to facilitate mass hosting of irssi. if you want to host multiple instances of irssi and allow those instances to bind and connect to any unreserved ports than you can set the irssi_unreserved_network boolean. this boolean will require all other booleans to be set as well for optimal performance. This scenario is for instances where you may have a shell server that hosts irssi on a machine in the dmz.So again theres four modes: 1. Disabled unless enabled. 2. Strict (can only connect to port 6667) 3. Single instance mode( can connect to 6667 and connect and bind to 4990-5000) and mass hosting mode ( can connect and bind to any unreserved port plus at of the above)
And ofcourse since this is a local (but not a user domain specific) boolean we will have to also declare this boolean in the irssi.te file in our module.
This next part goes into local* policy that defines how our domain may interact. This is usually the first piece of policy in the local policy block of your module and in this case it is user domain specific and thus should this be in the interface file irssi.if.
This piece of policy i split into 3 parts, Part 1 is policy that governs how our domain can interact with its own process (allow $1_irssi_t self). Part 2 is policy that governs how user domains may interact with the application domain e.g. allow $2 $1_irssi_t. Part 3 is policy that governs how our application domain may interact with the userdomain or allow $1_irssi_t $2)
Now i will deal with our domains objects and how our domain can interact with these objects. First you may remember that we declared a type irssi_etc_t in our irssi.te file. This is a global configuration file that irssi should be able to read,.and so we should give our domain access to search /etc, and we should allow our domain read and get attribute access to files with type irssi_etc_t. This will allow irssi to read the global config file.
Next we must ensure that irssi can manage its userdomain specific objects in the user space. We must ensure that the userdomain can also manage irssi objects in the user home location.
Third we should ensure that the userdomain is able to relabel irssi domain objects in his or her home dir. So that a user can move objects in and out of the irssi domain in his or her home location.
Most of our policy is done now. There are some interfaces that we have to call in other domains. One particular issue is that the userdomain should be able to read the application domains process. This is for using ps auxZ , top and etcetera.Also note the optional_policy block for nis_use_ypbind. The optional policy block means that the policy is only enabled when NIS is available. This option was added to add NIS support to our module.
Done! lets clean up the project
Now i have to copy my project to my desktop and archive it with exactly the same name as the serepolicy-3.3.1.tgz we extracted and prepared earlier.
Next we should create our personal rpmbuild root
In this part we are going to copy the contents of the folder that we have extracted from our source rpm in our Download location to the newly created SOURCES location in our ~/rpmbuild root.
we will remove the copied *.patch and serefpolicy-3.3.1.tgz from our ~/rpmbuild/SOURCES location and copy the selinux-policy.spec that is is also located there to ~/rpmbuild/SPECS/.
Next we will copy our modified serefpolicy-3.3.1.tgz from our desktop to the ~/.rpmbuild/SOURCES/ location.
Now we should edit our spec file located in ~/rpmbuild/SPECS/selinux-policy-spec. We have to bump up the version number to avoid difficulties. We also have to comment out any patch entries (this is because we already applied the included patches manually in the beginning of our exercise.)
Finally we should add our new module to the modules-targeted.conf file in ~/rpmbuild/SOURCES/ if we want our module to be active in the selinux-policy-targeted package.
Now we can execute rpmbuild -ba ~/rpmbuild/SPECS/selinux-policy.spec and let her rip.
If all (would) go well than you'd get your freshly brewed set of rpms.
But all did not went go well in this example as i made a mistake. The image below shows my mistake corrected. If you have any questions or comments please ping me at #fedora-selinux on freenode
You can find a copy of my irssi policy here http://pastebin.ca/768256?srch=irssi_exec_t it also includes policy for eggdrop and manual pages but it may need some work.
Abonneren op:
Posts (Atom)