If you can't understand it choose other language...
[English] [Russian ] [French] [Czech] [Japanese] [Translate and add your
language]
RSBAC for beginners.
Introduction.
Before beginning to turn you computer into a fortress you should think
of what you want. Any security system makes a lot of restrictions in
your life, and a great security system makes great restrictions.
Additional checks and authorizations lower productivity of a kernel, and
such things as safe delete lower speed of file system.
Forget about the superuser, it's one of the most serious security
problems. Now you have separately System administrator and Security
Officer. Both cannot influence against each other and even will compete
for authority in system. System administrator can still operate the
system, make settings, add and delete users, limit use by users of
system resources. Security officer will limit all users (including the
System Administrator) in access to any data, including system. For
example, administrator can add/remove users, but cannot edit manually
the files /etc/passwd and /etc/shadow if not allowed by the Security
Officer.
CAUTION!! Be careful at making the next changes, you may deny access to
EVERYTHING in your system, at a point where even single user mode would
not help you (against a kernel there is no reception). Your only rescue
would be to boot a system with a standard Linux kernel.
So, if you are not afraid of the problems mentioned above then let's go!
Otherwise, stick to the classic UNIX security system...
Kernel creation.
What you need:
1. main tarball - rsbac-version.tar.gz or rsbac-version.tar.bz2
2. admin utils - rsbac-admin-version.tar.gz
3. kernel patch
Download the latest RSBAC version (
http://www.rsbac.org/). You need two
archives: rsbac-current-version.tar.gz and
rsbac-admin-current-versions.tar.gz. The first archive contains the
kernel patches and the main RSBAC code, and the second contains the
administration utilities.
You need to add a new user, secoff with UID 400. Then during the first
system boot he will automatically become the Security Officer.
Unpack the kernel to /usr/src/linux, unpack rsbac-current-version.tar.gz
in the same directory and apply RSBAC kernel patch to the kernel :
patch -p1<patch-kernel-version. The kernel patch that you need for your
kernel version can be found at
http://www.rsbac.org/ in the Patch
directory. In version 1.0.9a and earler you can find patches in main
tar-ball.
Then 'make menuconfig' and see the new menu item "Rule Set Based Access
Control (RSBAC)". Welcome to RSBAC !
Make standard kernel tuning and go to RSBAC menu item. Check items
listed above:
* RSBAC proc support - You will see in /proc subdirectory a file
rsbac-info. You need it for administration utilities to work properly.
After having made RSBAC settings you can remove this item, so intruders
will not know about the existence of RSBAC.
* RSBAC maintenance kernel - Make two kernels. One with this item
enabled (that we will call the Maintenance Kernel) and one with this
item disabled (Main kernel). The maintenance kernel gives you a last
chance to administer the system almost normally as root and can be used
as a rescue kernel when you lost the control of the normal rsbac system.
* support secure_delete - It's not real secure deletion, only zero
filling. If you enable this item, the filesystem performance will be
lower.
RSBAC has modular structure, it contains some authentication modules,
each of which checks access in a special way. The final decision is
taken after consulting all modules.
All modules work independently, except the AUTH module, which is used by
all modules.
We will in this article only see four RSBAC modules. They are:
* AUTH - general process tracking. Programs can't change its UID to
another if you don't allow it to.
* RC (Role Compatibility) - Very serious role based model access. It
is useful and interesting. By using RC you can solve a great part of
your security problems.
* MAC (Mandatory Access Control) - Mandatory model of access based
on well known Bell-La Padula model. It very useful for security theory
and very difficult in real life.
* ACL (Access Control Lists) - You can define access permissions for
each user in the system.
You should enable these modules and disable all others. Be sure,
that in selected items you enabled only "NAME-OF-MODULE protection for
AUTH module", and NOT "NAME-OF-MODULE protection by role"
After this settings are done, make your kernels: Main kernel and
Maintenance kernel. First make your Main kernel and copy it to /boot,
then enable " RSBAC maintenance kernel" menu item and remake the kernel.
Now we need to make the administration utilities. Unpack
rsbac-admin-*-*.tar.gz in any directory. Then make and install the
utilities. You will probably have to change the parameter KERNELDIR in
the Makefile.
When you install the utilities, a directory /rsbac will be created. It's
your access database in the future. When you lost access to the system
after some experiments you can remove all files in this directory,
excluding useraci (You should do it under your usual kernel). You should
also remove /rsbac directories at all mounted partitions.
Important change in 1.0.9b: The admin tools install does not create
/rsbac anymore. Instead, kernel part creates rsbac/useraci (not realy
creates file, only default setting), if it does not exist. So, you
should also remove useraci. If you don't, there might be users with
unconfigured roles. This was the main reason for the kernel creating
useraci automatically.
So, you have the kernel and the utilities. We may continue. After the
first booting some services won't work, everyone will curse you, and
only root can login to the system. Don't worry, everything is OK. We
restrict permissions of the programs, that's why they don't work. We
will tune our restricted permissions and the system will begin to work
again. First, we need to login on the system as Security Officer. The
first way, is to reboot system with the new kernel parameter
rsbac_auth_enable_login (you need to append this parameter only the
first time). The second way, is to reboot with your maintenance kernel,
to login as root and to enter the command:
attr_set_fd FILE auth_may_setuid /bin/login
After this, boot the system, login as Security Officer, and go to your
book shelf to read the theory of security models.
AUTH module
This module controls Process UID changing. It has the following
parameters for each file:
* auth_may_setuid - Process work as with usual kernel. So, It can
change UID without any restrictions. /bin/login must have this
permission.
* auth_capabilities - List of UID's process can change to. For
example, when there are 23,25 an 45 in list, then process can change
it's UID to 23,25,45 and not to 66.
EXERCISE: Now we can correct some errors with services that we saw at
the first startup. First look in the system logs (secoff is an ordinary
user, you need root privileges for that) and find the error messages. If
you can find message like the one listed below then we can solve this
problem now, otherwise we'll do it later.
Feb 25 12:58:13 stas kernel: rsbac_adf_request(): request CHANGE_OWNER,
caller_pid 77, caller_prog_name portmap, caller_uid 0, target-type
PROCESS, tid 77, attr owner, value 1, result NOT_GRANTED by AUTH
This message explain us, that the process portmap with current UID 0
tried change it (CHANGE_OWNER) to 1 (value 1) and AUTH module rejected
this request. Well, we can tell to RSBAC that portmap can do it, e.g.
add UID 1 to auth_capabilities list.
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
NOTE: (How RSBAC prints log messages)
In general, RSBAC use following scheme of kernel messages:
---------------------------------------------
Kernel
---------- ----------------
| | | |
| printk | | rsbac_printk |
| kernel | | kernel |
| buffer | | buffer |
---------- ----------------
----|-----------------|----------------------
/proc/kmsg /proc/rsbac-info/rmsg
| |
| |
klogd rklogd (or other program)
| |
| |
| /home/secoff/rsbac-messages
syslogd
|
|
/var/log/messages
RSBAC can use standart syslog features or use own loggging facility
through /proc/rsbac-info/rmsg (or rsbac_syslog() system call) file.
Only security officer can read RSBAC messages in this way. If you don't
want fill /var/log with RSBAC messages or you want to protect security
messages, you should enable corresponding menu item ("don't log to
syslog") during kernel configuration stage.
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Login as security officer and run main administration program
"rsbac_menu". Go to "File/Dir Attributes menu"... Are you ready to this
big list of possible permissions you see? This is a result of RSBAC
having a modular structure. Each module ( and security model) has its
own permission mapping.
Let's work. Select the file portmap using "File/Dir List:Choose from
listing of last dir" menu. Then go to auth_capabilities menu and add new
UID 1. Now the program portmap is configured and will not swear at the
next startup.
Use a similar method to correct other error messages. As shows my
experience, after this little work, the system will work as before.
MAC Module
AUTH model is very powerful, but very simple. Other models are not so
easy to understand. MAC module realizes model offered by Bell and La
Padula for Multics Operation System. At first we should familiarize with
the theory.
There are two sets: the set of objects O and the set of subjects S.
Objects are files, directories, shared memory, pipes, message queues and
other system resources. Subjects are users and processes they start.
Subjects try to get access to Objects. The security system check the
permissions of the Subject and allows or rejects the action. It's clear
that the system needs certain criteria to make this decision. In
Mandatory Access Model criteria are Mandatory Label.
Mandatory Label consists of Security Level L (non negative number) and
Set of Categories M (64-bit vector).
Category M1 dominates over Category M2 (by definition) if for each 1 in
the second vector corresponds 1 in the first vector.
example (in 3-bit vector)
M1 {1,0,1} dominates over M1 {1,0,0}
M3 {0,0,1} dominates over M4 {0,0,0}
The Label {Li,Mi} dominates over the label {Lj,Mj} (by definition) if
Li>Lj and Mi dominates over Mj.
With this definitions we also need some special rules.
First, we need to use an access matrix D where Dij contains the
permissions of the subject Si to the object Oj (read, write, execute and
maybe others...). We don't have special access matrix in RSBAC and use
standard UNIX rules.
There are also the following additional decision rules (from main RSBAC
documentation):
1.ss-property: Si dominates Oj, if x = r or x = w (x contains read
access).
2.*-property: Si is trusted or
1.Oj dominates current level of Si, if mode = a
2.level of Oj is equal to the current level of Si, if mode = w
3.current level of Si dominates level of Oj, if mode = r
3.ds-property: x is in cell Mi,j of matrix M of authorized accesses
As you see it's a very difficult model. In real life great part of
programs will not work properly. So, I recommend that you use it, only
if you perfectly know what you want to do.
EXERCISE: Let's see MAC file and user attributes. Login as user "test".
Create file /tmp/mactest, enter as security officer and run main
administration program rsbac_menu. Go to "File/Dir Attributes menu".
Choose /tmp/mactest file. There are MAC file attributes:
* MAC security level - Set it into 2.
* MAC categories - Don't touch it.
* MAC trusted for user - Special case: the file can trust the user,
despite his Security Level. It use only for executables.
Now try to open the file (for example, using cat) under user "test". The
security system rejects the access, despite the fact that you have an
access conform with standard UNIX permissions. We need a higher security
level to access this file.
Run rsbac_menu and go to "User Attributes: Go to user attribute menu "
menu... Oh, user has too many rights. Choose user "test". We need to
check two of his rights:
* Security Level - User can read document if his own level is not
lower than the level of document. Set it to 2.
* MAC Categories - Set of user categories.
Now the user test can work with the file mactest.
ATTENTION: MAC only allow to process change security level not higher
then current one. So, if user Peter has level 0 and user John has level
2, then Peter's process cannot change UID to John's one. It's main
reason root has maximum security level.
EXERCISE FOR DEVELOPERS:
Solve problem with root's security level. One solution may be to add a
new "Enforced MAC security level" level attribute to file (like RC
enforced role).
ACL module
Well you have enough knowledge for today?... No? Then go to ACL. Each
file has one vector of permissions (wrxwrxwrx). Using a vector we can
assign access permissions to the owner, to a group of users and to
"others". But we want assign permissions to each users . For example,
for user1 (wr-) , for user2 (w-x) and for group1 (--x). So, we need a
list of permissions - access control lists (ACL). For these reasons we
have included ACL module. It expands standard UNIX permissions.
EXERCISE: Please, create /tmp/acltest directory, run rsbac_menu program,
go to file rights menu and then to " ACL Menu: Go to ACL menu "... Where
are the permissions ? Don't worry, press
"Change mask" and ...
* ADD_TO_KERNEL - for kernel modules (drivers).
* ALTER - Change control information for IPC
* APPEND_OPEN
* CHANGE_GROUP
* CHANGE_OWNER
* CHDIR
* CLONE-clone() or fork() call.
* CLOSE
* CREATE
* DELETE
* EXECUTE
* GET_PERMISSIONS_DATA-get UNIX permissions.
* GET_STATUS_DATA- stat() system call.
* LINK_HARD
* MODIFY_ACCESS_DATA-Modify access time.
* MODIFY_ATTRIBUTE-Modify RSBAC attribute.
* MODIFY_PERMISSIONS_DATA- Modify UNIX permissions.
* MODIFY_SYSTEM_DATA- Change system data (ports,...).
* MOUNT
* READ
* READ_ATTRIBUTE- Read RSBAC attribute.
* READ_OPEN
* READ_WRITE_OPEN
* REMOVE_FROM_KERNEL- for kernel modules (drivers)
* RENAME
* SEARCH
* SEND_SIGNAL-send signal to other process
* SHUTDOWN
* SWITCH_LOG-switch RSBAC log levels.
* SWITCH_MODULE-switch RSBAC module.
* TERMINATE- terminate process
* TRACE- trace process (ptrace() call).
* TRUNCATE
* UMOUNT
* WRITE
* WRITE_OPEN
Ohh... that is all. You can enable/disable each of the attributes, but
we will test only one of them now.
Disable for /tmp/acltest directory the CHDIR permission. Now nothing can
change to this directory. We change the general mask, but we can add new
(ACL entry) for certain user, group or role (about role see "RC module"
chapter).
Choose "Add ACL Entry:Add group, role or user entry" menu item and then
say we want to add a user. Choose the user from the list (for example,
user tttt). You can change the mask for this user now. Select this mask
and enable all permissions in the vector. Test the result.
The user tttt and only the user tttt can change directory to
/tmp/acltest. (Security Officer can change dir too, but you can
restrict his access by ordinary UNIX rights!)
You can also add entries to group of users (ACL group) and RC-role. But
you need to read the description of RC before.
ATTENTION:
If you remove all rights to all users from ACL mask of some file,
security officer still will have access to this file. It's result
SUPERVISOR right in mask. You can also remove SUPERVISOR in the
/tmp/acltest mask under certain conditions: if enabled in kernel config
and you have a personal user ACL entry with SUPERVISOR in it.
EXERCISE:
Another interesting feature in ACL is inheritance. You can change
:DEFAULT: ACL rights to some types of targets: users, files, etc. Test
it.
Be carefull. If you remove some ACL rights to security officer you can
lost all chances to change ACL settings.
RC Module
Do you like the theater?... Yes? Then it will be easy for you to
understand the idea of role. Otherwise you must read the following text.
First, the key words are targets and requests.
A subject makes a request of access to a target. Requests have same ACL
permissions (CHDIR, APPEND_OPEN, ....).
Targets are: FILE, DIR, DEV, IPC (semaphore, message queue, pipe,...),
SCD(System Control Data. For example, ports, kernel logs
..),USER,PROCESS,NONE(empty target),FD(file descriptor, FILE and DIR
together).
Each target has a type. You can use default type (System FD, Security
FD,...) of create a new one.
Role is a class of subjects. Role defines this class of permissions to
defined targets and other roles.
There are general role parameters:
* Name -Name of the role
* Role Comp- List of the roles this role can switch without change
owner.
* Admin Roles -List of the roles this role can administrate (change
parameters).
* Assign Roles -List of the roles this role can assign to users and
processes (using administration utilities).
* Type comp FD- ACL permissions of this role for all types of target
FD..
* Type comp DEV-same, permissions for target DEV.
* Type comp Process-same, permissions for target Process.
* Type comp IPC-same, permissions for target IPC.
* Type comp SCD- same, permissions for target SCD.
* Admin Type- Type of role. You can also use the first four
parameters (RC separation of duty facility) instead of this. Type may be
: General User, System Admin or Role Admin.
* Default FD Create Type - Type of target or inherit from ...
* Default Process Create Type
* Default Process Chown Type
* Default Process Execute Type
* Default IPC Create Type
Is it difficult? Yes, it's difficult, but it very powerful too. You can
make flexible settings and achieve fantastic results.
For example, the administrator can add/remove users, but cannot edit
manually the files /etc/passwd and /etc/shadow, after our settings. It
may be very useful for a Web-site. Then intruders cannot remove the
first Web-page, even though they have root access. Only Apache can work
with this page.
EXERCISE: First, create a new target type - Passwd FD. Make it using the
"RC Types" menu. Then make a new role Admin Passwd. Go to menu "RC
Roles", choose the role "System Administrator" (using "Rolelist: Choose
role from list" menu) and copy to the new role (" Copy Role (New Role)"
menu item). Rename the new role to Admin Passwd. Change the ACL
permissions of this role to target "Passwd FD" (set full permissions,
other roles has no rights to this target by default). Add to System
Admin role the permission to read this target (read-only not
read-write!).
Well, the model is ready. Apply it to your real objects. Be very careful
, you can loose access to your own system. A good idea is to try to
login-in using one virtual console and make settings using another one.
Run rsbac_menu. Go to the file attributes menu and find the parameter:
* RC Type FD - Type of this target concerning RC model.
choose the file /etc/passwd and set the value Passwd FD. Now root
(System Admin) has read-only access to this file. DON'T logout for the
moment!
Choose the file /bin/login and find the following attribute:
* RC Force Role- Role applied to process. It's the same as the
SUID-bit in UNIX. The program will be run by root (System Admin), but
the process will have another role.
Set this value to "Admin Passwd". Now login has full access to
/etc/passwd.
You can also give full access to useradd and userdel programs. So
programs has full permissions, but root can only read files. The system
protected by RSBAC.
Other interesting RSBAC modules.
FF Module.
There is another interesting RSBAC module -File Flags. Using this module
you can eazy assign rights to whole directory trees. You can, e.g.,
assign "read_only" flag to
/bin
/sbin
/usr/bin
/usr/sbin
Then all users can execute programs,they need, but nobody can destroy
files. Interesting feature is FF inheritance. You can remove inheritance
for selected file by turning off "add_inherited" flag. So, you can make
"read_only" /etc directory with writable /etc/mtab file.
File flags list:
* no_execute -you can apply this flag to /home, so users cannot
execute
* self compiled programs without signing by secoff..
* secure_delete - enable secure deletion to file.
* write_only - protect your files from reading (for example,log
files)
* search_only - usefull only for directories.
* execute_only -no comments.
* read_only-no comments.
FF is very eazy and powerfull module.
ATENTION: If you enable "FF Role Protection" feature during kernel
config, you cannot login to system as security officer. FF will prevent
CHANGE_OWNER from administrator to security officer. You will have to
login as general user and make su to officer.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
NOTE:"Role Protection" comes from older RSBAC version when AUTH module
not be written yet. This feature has all RSBAC modules (exluding AUTH)
and works same in FF.
But RC uses its own rc_role (instead system_role), and you can set the
intermediate role (the one that must always be changed to or from) at
compile time. Default is 0, the predefined General_User.
This feature gives a lot of restrictions and still not really secure.
This is the reason why the default config has Role Protection turned
off, but AUTH turned on.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
RSBAC Distribution
All things you seen you can eazy get by using ready RSBAC distribution.
Now we have a beta of ALT Linux Castle - first RSBAC-based Linux
distribution. See page
http://people.altlinux.ru/inger/index-en.html
for details
Conclusion.
We have discussed only some of the RSBAC decision modules. You can see
others yourself and send questions to me or to RSBAC mailing list. I'm
going to write new articles about this great Security System. In
conclusion here are some exercises for you:
* You can make own decision module and insert them inside the
kernel as a driver (You should enable "REG module" feature during the
kernel configuration)
* You can switch modules on-the-fly (You should enable "Switch
modules" feature during the kernel configuration)
* You can move RSBAC ACI (Access Control Information) database from
/rsbac to another directory. Change corresponding value in
/usr/src/linux/include/rsbac/aci_data_structures.h. You can also use it
for dufferent RSBAC configurations.
* You can develop your own RSBAC modules.
So, you can develop, improve, enjoy RSBAC and tell us your results!
The show must go on...
Stanislav Ievlev <
[email protected]>
Translation from Russian into English by:
Stanislav Ievlev <
[email protected]>
Konstantin Volkov <
[email protected]>
and Fabrice Marie <
[email protected]>
