collected: SELinux-module example for mod_tile

posted by on 2012.02.05, under collected, configuration, linux, security
05:

For a project@work I had to setup an open street map server on Scientific Linux 6.1 (64 bit) for rendering the map of the BRD. For this I installed all needed components – and run into big trouble with mod_tile. This module is responsible for taking queries for map-tiles from the apache, forward it to the render daemon and deliver the images back. mod_tile and renderd communicate via an unix socket. And SELinux prevents mod_tile – that runs in the context of httpd – to access the socket. A short grep of the web gives a general answer: disable SELinux. Since SELinux was also a long time common problem to me (yes, I used echo „0“ > /selinux/enforce some times) I decided to accept the challenge… and after reading a lot I got a solution:=).

The following description should work in general if you have trouble with „access-denied-by-SELinux“-problems. The process is quite easy: use the output of the SELinux-audit-logging for create a probate module. Step by step:

0. be sure that SELinux is your problem. Maybe you got error messages like „permission denied“ when accessing files – and you already give full access via chmod/ (if the application gives no output use strace and grep for EACCES, use -e trace=… to filter systemcalls) and/or set the correct security context by chcon/restorecon. Have a look at the boolean shortcuts (getsebool -a | grep ) to check if there is an option to permit the needed action/access.

1. check SELinux-audit-log (/var/log/audit/audit.log) for entries that are related to your problem. If there is nothing enable audit by restart your machine with an additional kernel parameter audit=1. For mod_tile we captured 2 entries:


type=AVC msg=audit(1328183212.312:383): avc:  denied  { connectto } for  pid=2314 comm="httpd" path="/var/run/renderd/renderd.sock" scontext=unconfined_u:system_r:httpd_t:s0 tcontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tclass=unix_stream_socket
type=AVC msg=audit(1328182336.427:158): avc:  denied  { write } for  pid=2017 comm="httpd" name="renderd.sock" dev=sda2 ino=2097727 scontext=unconfined_u:system_r:httpd_t:s0 tcontext=unconfined_u:object_r:var_run_t:s0 tclass=sock_file

Put the relevant entries into a separate file like audit.out.

2a.build module the long way – so you see what happens…


/*build the module description aka "the source" into apachemodtile.te*/
#>cat audit.out | audit2allow -m apachemodtile > apachemodtile.te
#>cat apachemodtile.te
module apachemodtile 1.0;
require {
type unconfined_t;
type var_run_t;
type httpd_t;
class sock_file write;
class unix_stream_socket connectto;
}
#============= httpd_t ==============
allow httpd_t unconfined_t:unix_stream_socket connectto;
allow httpd_t var_run_t:sock_file write;

/*build the binary module apachemodtile.mod*/
#>checkmodule -M -m -o apachemodtile.mod apachemodtile.te
/*build a SELinux policy module package in apachemodtile.pp*/
#>semodule_package -o apachemodtile.pp -m apachemodtile.mod

2b. use audit2module – does all of 2a in one step:


#>cat audit.out | audit2allow -M apachemodtile

3. install the module permanently:


/*modul goes (SL61) to /etc/selinux/targeted/modules/active/modules/apachemodtile.pp*/
#>semodule -i apachemodtile.pp

After this mod_tile was able to connect to the socket of the renderd. Quite easy 🙂

collected: screen

posted by on 2011.04.04, under collected, commands, debug, linux
04:

this is a plain collector article about gnu screen. in the early days I used screen only for running processes that should last after I’ve logged out. now-days it’s comfortable for debugging programs and/or running [virtual] kernels/machines in one terminal. to screen-able your shell simply run screen (>screen). the following snipped gives a short overview about the most common shortcuts you could use in screen…

(C = CTRL)

C+a c          new screen-session
C+a A          set name for the window
C+a w          show list of all windows in status bar
C+a "          show list of all windows (up/down for select, enter to open)
C+a N          show number and title of current window
C+a '          switch to given window (0..n + enter)
C+a 1…n        switch to window with given number
C+a n          switch to next window
C+a p          switch to previous window

C+a S          split current window horizontally
C+a |          split current window vertically
C+a TAB        switch to the next region
C+a X          close the current region
C+a Q          close all regions but the current
C+a q          send C+q to the current region

C+a d          detach window from terminal
               reattach with screen -r <pid_of_screen>

C+a ESC       
C+a [          start copy and scroll mode, use cursor up/down for scrolling/move cursor
               press enter to start marking text, press enter second time->marked text is copied to buffer
C+a ]          paste current buffer to stdout
C+a >          paste current buffer to /tmp/screen-exchange
C+a <          read data from /tmp/screen-exchange

C+a :          screen command prompt
C+a ?          list key-bindings  
C+a v          outputs screen version
C+a K          exit&close screen session

you can also define your own bindings and beside the already bounded commands there are tons of it you can use in the screen-prompt (have a look to the man’s, most used by me is hardcopy -h – it simply dumps the current content of the region into a file).

module development for GRUB2 – playground

posted by on 2011.02.19, under bootloader, linux, programming
19:

Since testing modules for GRUB by compile/reboot/test/boot/… is time consuming, frustrating – simply not very efficient, there was an utility shipped with the sources called grub-emu that (like the name states) emulates the grub console. But: it was/is not a perfect emulation (stm), no modules are loaded/loadable so every module must be hand-coded-added to the built and… it does not build (like descibed here).

The playground – world:

And thats is okay cause there is another great tool: grub_mkrescue – an image builder that creates floppy/cdrom-images with… grub on it. (and it supports the preloading of modules) Sample:

$m[2]

Gives a GRUB inside qemu with hello.mod already loaded. Fine. Put the lines into the Makefile of the module currently developed (maybe as run-target) and testing becomes a lot easier…

The playground – garden:

Assume you have checked out the (latest) sources of grub2, and now you stay into the source-dir grub-1.98. Your new module (for the firsttime a copy/paste/change of hello/hello.c) goes to grub-1.98/simplemod.

Building a module could be done two ways: the slower one by adding a probate entry in conf/common.mk (simple copy/paste an entry for a given module like hello) – results in building everything again, and again when calling make clean/make… or the good, fast and due to the handcrafted standalone-Makefile ugly one.
No more filling phrases… here is the makefile (to be placed in grub-1.98/simplemod/Makefile):

$m[2]

Okay, on the first time you must create the surrounding grub2-ecosystem (grub-1.98/configure;make;make install). But after that you only need to compile your new module. That is efficient.

Fedora 14 & GRUB2

posted by on 2011.02.19, under bootloader, configuration, linux
19:

Forced by a project@work I had to install GRUB2 in Fedora 14. Here is a simple description of what I have done to got it running:

1. install the new „grand unified bootloader package“ by

$m[2]

Attention: at this time, Fedora uses multislot – GRUB Legacy (0.9x) and GRUB2 could be installed parallel.

2. edit/create the new /boot/grub2/grub.cfg

2.1 My old /boot/grub/grub.conf looks like:
$m[2]

In the snipped above you could see that GRUB2 is allready inserted into the grub.conf of your old GRUB. You could use it for boot into the GRUB command-line.

2.2. create a new grub.cfg
Important: in GRUB Legacy (the old GRUB) the partition-numbering starts with 0. In GRUB2 the numbering starts with 1. So hd0,0 from above becomes hd0,1 eg.
Check/note on witch device/partition your /boot and root is located and witch UUID it has assigned (mount gives you the device /dev/sd…, blkid the associated UUID), sample:
$m[2]


3. Now run
$m[2]

The output is placed into /boot/grub2/grub.cfg.new – do a cat on it and compare the UUID for /boot and root with the ones from above (and maybe compare against your old grub.conf) … and yes, hd0,0 is now hd0,1 .

4. The final step: install the new GRUB on the disc…
First only test that everything is fine… (without writing to MBR assuming the target drive is /dev/sda):
$m[2]

Now lets use the real bullet:
$m[2]


5. Finally
$m[2]


And it works. For me. Now.

GRUB2 offers 1000nds new possibilities (ohh, it has a LUA-shell, there is module-support, submenus, theming, …)

For learning: boot the core.img, load kernel and ramdisk by hand. boot. check console commads ls & cat.

Have a look at:
http://www.gnu.org/software/grub/manual/
http://ubuntuforums.org/showthread.php?t=1195275

pagetop