Current version
Git/Latestdiff: 1.5.6
Latest Snapshots
Produced after each commit or rebase to new upstream version
GIT
RSBAC source code, can be unstable sometimes
No events planned
Configuration Basics
How to Identify Security Requirements on a System Identify execution flows on the system What can trigger an execution Boot process (for running daemons / services) External interaction (users, other systems) Scheduling For each separate execution flow, create a role For each role, identify the execution flow starting point Boot process : init External interaction : login, sudo, su, ssh Scheduling : cron, at For each role, identify the resources used Filesystem use Read access ? where ? Write access ? where ? Exec access ? where ? Devices Role-dependant : networking : setup a correct firewall, identify devices for interaction CPU / Memory / ... How much ? The role specification allows admin to completely forbid access to the "default role", so that something unusual happening will be blocked. Users, User IDs and Paths You need to identify who/what needs an access to which resources. Roles usually can be represented by one account each. Create specific accounts for specific tasks, users or group of users. Choose wether the accounts database will be managed by RSBAC or not : if the database needs to be managed by RSBAC, choose the USER MODE (UM) module, prepare the PAM module for RSBAC but don't activate it. Load the groups db into RSBAC first ("rsbac_groupadd -O"), then users db into RSBAC ("rsbac_useradd -O"), then set a password manually for each user who needs one ("rsbac_password [...]") (no, we can't crack MD5 to automate SHA1 hashes creation...) Choose a password policy : how complex and long should your users' passwords needs to be ? When do they need to be changed ? If you think you need guest-like accounts to the system, think twice wether or not you really need them. Identify the minimal resources and accesses that should be available (the "minimal-rights" profile). Use PAM-chroot with RSBAC-jail when you can use it. System Base Filesystem (Read, Write, Exec...) Base binaries and libraries Identify places where binaries should be executed : $PATH, some specific users' $HOME/bin directories... Forbid execution on places different than above identified. Prevent tampering by forbidding write access for system-wide directories. Do you need a scheduled integrity checker ? Kernel (/boot) Prevent any access to /boot apart from the boot process role. Do you really need some apps to access System.map ? Devices (/dev) Static /dev or UDEV ? Disable any filesystem modification if you can afford it. Identify needed /dev files for console or remote logins. Configuration (/etc) : details ? Homes (/home, /root) : only allow roles to access its own account(s)' home. System info (/proc, /sys) : prevent access to unneeded information, prevent mem reading Mail, Sockets, Spoolers (/var) : protect mail, logs (see logs) Temporary data (/tmp) : sticky, noexec (nodev?-socket) Alternate Apps, Removable media (/opt ...) Processes Running daemons (cron/atd, clamd, *logd, getties...) : what processes ? when ? run by whom ? Scheduled daemons (mail daemon, logrotate...) : identify them User processes : are there any (human) user processes which needs to run while he's not logged ? Network services Identifying needed services : do you really need it ? when does it need to be opened ? Identify interaction capabilities (remote, local, ...) Firewalling : filtering, port < 1024 guarantees root owner? Logging Current log files (cf filesystem) : identify processes / users who needs access to /var/log, prevent the rest to access Log archiving Selecting a Security Model Combination General Criteria Model Specifics Experiences Breaking the Requirements into Model Specific Designs Sample System Select Simple System Type Specify Requirements Select Models Design a Configuration Implement it FIXME Administration Examples Learning Mode