Konusmaci olarak katildigim Ozgur Yazilim ve Linux Gunleri’15 kapsaminda, SELinux: Yüksek Güvenlikli Linux Kernel hakkinda yaptigim sunumumu asagidaki baglantida bulabilirsiniz.
During the building operations of bash 4.3.30 using buildroot, some errors may occur:
bashline.o: In function `bash_event_hook': bashline.c:(.text+0x2328): undefined reference to `rl_signal_event_hook' bashline.o: In function `bash_execute_unix_command': bashline.c:(.text+0x2d5c): undefined reference to `rl_executing_keyseq' bashline.o: In function `bashline_set_event_hook': bashline.c:(.text+0x3734): undefined reference to `rl_signal_event_hook' bashline.o: In function `bashline_reset_event_hook': bashline.c:(.text+0x3748): undefined reference to `rl_signal_event_hook' bashline.o: In function `initialize_readline': bashline.c:(.text+0x4464): undefined reference to `rl_filename_stat_hook' bashline.o: In function `attempt_shell_completion': bashline.c:(.text+0x4b0c): undefined reference to `rl_filename_stat_hook' bashline.o: In function `bashline_reset': bashline.c:(.text+0x4bb8): undefined reference to `rl_filename_stat_hook' bashline.c:(.text+0x4bc0): undefined reference to `rl_signal_event_hook' bashline.o: In function `command_word_completion_function': bashline.c:(.text+0x572c): undefined reference to `rl_filename_stat_hook' collect2: error: ld returned 1 exit status make: *** [bash] Error 1
This error may depend on your external toolchain, however solution is as easy as making symlink. Main source of this error comes from readline library. It seems that readline 6.2 & 6 (afaik) do not have above functions.
In buildroot sysroot directory,
libreadline.so exists in usr/lib/arm-linux-gnueabihf and linked to lib/arm-linux-gnueabihf/libreadline.so.6 which also linked to libreadline.so.6.2. Changing this linkage to libreadline.so.6.3:
cp usr/lib/libreadline.so.6.3 lib/arm-linux-gnueabihf/ cd usr/lib ln -sf libreadline.so.6.3 libreadline.so.6
should solve the build problem.
libcgroup is an abstraction of a linux cgroups. Even though standard cross-compile operations are fairly enough:
./configure --host=arm-linux-gnueabihf make
During compilation, this error happens:
make: Entering directory `/home/arcelik/1511/tools/libcgroup-0.41/src/daemon' CC cgrulesengd.o CCLD cgrulesengd cgrulesengd.o: In function `cgre_store_unchanged_process': /home/arcelik/1511/tools/libcgroup-0.41/src/daemon/cgrulesengd.c:310: undefined reference to `rpl_realloc' cgrulesengd.o: In function `cgre_store_parent_info': /home/arcelik/1511/tools/libcgroup-0.41/src/daemon/cgrulesengd.c:223: undefined reference to `rpl_realloc' ../../src/.libs/libcgroup.so: undefined reference to `rpl_malloc' collect2: error: ld returned 1 exit status
undefined reference to rpl_malloc and rpl_realloc error can be fixed by explicitly telling the configure script that malloc and realloc functions are exist. So that, above linking error should not happen.
However, target platform has to be a glibc system to avoid from runtime error in the future.
ac_cv_func_malloc_0_nonnull=yes ac_cv_func_realloc_0_nonnull=yes ./configure --host=arm-linux-gnueabihf make
Note: an extension of a linaro toolchain 2014.09 is used while cross-compiling. https://github.com/eckucukoglu/arm-linux-gnueabihf.git
There exists some blog posts, articles about SELinux mode configuration already, which easily can be found by searching on google: “how to enable/disable selinux, how to configure selinux”. Moreover, The SELinux Notebook 4th edition has information about SELinux modes and global configuration files, respectively in chapter 2.15 and 3.2.1. However, I think, SELinux has some controversial issues about mode configuration and none of these resources are good enough to clear the mind about confusing SELinux mode configuration.
First of all, linux kernel has some configuration options which allows/disallows SELinux to be disabled/enabled. These options are:
So far, we know that these arguments can be passed to kernel:
Additionally, from Dan Walsh’s blogpost, there is also
boot argument to relabel the system with exact security contexts.
Furthermore, another way to configure SELinux modes is global configuration file: /etc/selinux/config
# This file controls the state of SELinux on the system. # SELINUX= can take one of these three values: # enforcing - SELinux security policy is enforced. # permissive - SELinux prints warnings instead of enforcing. # disabled - No SELinux policy is loaded.
According to these options, SELinux modes can be changed. However which option overrides the other one is confusing.
Two way to switch between permissive and enforcing at runtime. Note that after reboot these options will be overriden by the system defaults. Moreover, switching to permissive/enforcing mode is only applicable unless selinux is disabled.
# switching to enforcing echo 1 > /sys/fs/selinux/enforce # switching to permissive echo 0 > /sys/fs/selinux/enforce
# switching to enforcing setenforce 1 /* or setenforce Enforcing */ # switching to permissive setenforce 0 /* or setenforce Permissive */
The second confusing thing about SELinux mode configuration is that even though kernel boot parameters override the config file, the exact opposite of this action is also possible. To clarify this options, I have made some tests on my running ARM platform. Note that, I compiled kernel with these configs:
CONFIG_SECURITY_SELINUX=y CONFIG_SECURITY_SELINUX_BOOTPARAM=y CONFIG_SECURITY_SELINUX_BOOTPARAM_VALUE=1 CONFIG_SECURITY_SELINUX_DISABLE=y CONFIG_SECURITY_SELINUX_DEVELOP=y CONFIG_SECURITY_SELINUX_AVC_STATS=y CONFIG_SECURITY_SELINUX_CHECKREQPROT_VALUE=1 # CONFIG_SECURITY_SELINUX_POLICYDB_VERSION_MAX is not set
So, boot argument selinux=0 overrides /etc/config/selinux, however selinux=1 does not overrides. Moreover, while passing enforcing=0, even though in /etc/selinux/config includes SELINUX=enforcing, system starts w/ permissive mode. However if config file includes SELINUX=disabled, system starts w/o SELinux. I think this is confusing and kind of inconsistent but there should be a good rationale for that. Most people hardly ever get confronted with these situations.
As mentioned gentoo:selinux tutorials and here, If system booted with SELinux disabled, we need to relabel filesystem to enable again SELinux. After disabling SELinux, switching back to enforcing mode causes kernel crash, since relabeling can not be possible in enforcing mode. So that, switching from disabled to enabled mode is only possible in permissive mode. After booting in permissive mode:
can be used to relabel filesystem. Also, kernel boot parameter
will force the system to relabel, too. In my experiments, after disabling SELinux, passing enforcing=1 as kernel parameters causes kernel panic (as expected). Here the logs:
[ 8.245513] SELinux: Disabled at runtime. [ 8.474853] type=1404 audit(946686015.345:2): selinux=0 auid=4294967295 ses=4294967295 can't load SELinux Policy. Machine is in enforcing mode. Halting now.
If your intention is to disable SELinux permanently, and never ever want to be enabled again, even though it is not recommended, passing selinux=0 as kernel boot parameter is the best option. For this case, kernel boot argument overrides options in /etc/selinux/config. However, unless SELinux is intented to be disabled, passing selinux=1 or none as kernel boot parameter and modifying /etc/selinux/config file, according to intention, will be proper action.
In linux, it is possible to extend the size of a disk image without losing already existed content.
For example, to extend rootfs image to a fixed 1GB size:
dd if=/dev/zero of=rootfs.ext2 bs=1M seek=1000 count=0 e2fsck -f rootfs.ext2 resize2fs rootfs.ext2
Redirection (>, <) and pipe (|), both are used to pass output of a process. However, there exists one fundamental differences between them. Even though redirection can be used to pass to stream which also can be a file, pipe can pass output of a process to another process.
For example, this command does that:
dmesg | grep selinux > temp.log
In fact, above-command can be typed like that:
dmesg > dmesg.out && grep selinux < dmesg.out > temp.log
Which does same job, except that it writes dmesg output to file named dmesg.out. Instead of double redirection, using pipe eases our job.