Linux Kongress 2008 + 1.4 getting near

Hello Everyone!

Linux Kongress talks will be 9th and 10th of October in Hamburg. I 
will be there and would like to meet more people interested in RSBAC.

My request for an RSBAC desk has not yet been answered, but such 
things usually get organized in the last two weeks.

RSBAC 1.4 will hopefully be out before that. I am still working on 
some occasional hangs with 2.6.26, which require internal changes 
with mounts/umounts and the RSBAC device lists. Apart from that, 1.4 
is ready and already working well on quite a few 2.4 kernel systems.

We have split up RSBAC development for 2.6 and 2.4 kernels, there have 
been way too many changes in 2.6 and we do not want to risk the 2.4 
code rock solid stability. Also, the code looks much cleaner after 
removing lots of ifdefs. We hope to keep the admin tools usuable for 
both 2.6 and 2.4, otherwise we will split the code, too.

Amon.
--

-- 
http://www.rsbac.org - GnuPG: 2048g/5DEAAA30 2002-10-22

pax break

Hi list,
i test the kernel 2.6.26.3 with this pax-linux-2.6.26.3-test20.patch.
this i get.

see append

is more with pax related but rsbacd is involved.

grüsse jens

 * Mounting devpts at /dev/pts ...                                        [ ok ]
 * Checking root filesystem .../sbin/fsck.xfs: XFS file system.                 
                                           [ ok ]                               
 * Remounting root filesystem read/write ...                              [ ok ]
PAX: suspicious general protection fault: 0000 [#1] PREEMPT                     
Modules linked in: nvidia(P) snd_ca0106 snd_rawmidi snd_seq_device i2c_viapro sn

Pid: 2896, comm: rsbacd Tainted: P          (2.6.26.3-rsbac-0.52-soft #3)       
EIP: 0060:[<00535500>] EFLAGS: 00010212 CPU: 0                                  
EIP is at xfs_da_hashname+0x20/0xd0 [xfs]                                       
EAX: 00000001 EBX: 00000000 ECX: 00000001 EDX: 00000008                         
ESI: 00000009 EDI: 00000001 EBP: 00000004 ESP: f6cc1d48                         
 DS: 0068 ES: 0068 FS: 0000 GS: 0000 SS: 0068                                   
Process rsbacd (pid: 2896, ti=f6cc0000 task=f789b1e0 task.ti=f6cc0000)          
Stack: f74c9a80 00000000 f6cc1dbc f6cc1d60 005397a6 f74bd5ec 00000001 00000008  
       00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000  
       00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000  
Call Trace:                                                                     

SERACH request on DEV target

Hi all,

I got an error message, when I try to run my own sh script. This script
uses some commands, for example "find".  The error message is:

0000012064|check_comp_rc(): pid 465296960 (find), owner 65534, rc_role
0, DEV rc_type 0, request SEARCH -> NOT_GRANTED!
<6>0000012065|rsbac_adf_request(): request SEARCH, pid 3764, ppid 3763,
prog_name find, prog_file /usr/bin/find, uid 65534, audit uid 400,
target_type DEV, tid block 07:05, attr none, value none, result
NOT_GRANTED by RC ACL

Now, my problem is, I did not found SEARCH request on DEV targets, so I
can not allow this request. I really need to allow this process to
collect data correctly, but RC and ACL blocks it. Do you have any idea?

I'm running RSBAC 1.3.8 with pre-patched kernel 2.6.24.3.

Thanks for your help,

Tamas

Re: SERACH request on DEV target

On Thursday 18 September 2008 21:06, Orosz Tamás wrote:
> I got an error message, when I try to run my own sh script. This
> script uses some commands, for example "find".  The error message
> is:
>
> 0000012064|check_comp_rc(): pid 465296960 (find), owner 65534,
> rc_role 0, DEV rc_type 0, request SEARCH -> NOT_GRANTED!
> <6>0000012065|rsbac_adf_request(): request SEARCH, pid 3764, ppid
> 3763, prog_name find, prog_file /usr/bin/find, uid 65534, audit uid
> 400, target_type DEV, tid block 07:05, attr none, value none,
> result NOT_GRANTED by RC ACL
>
> Now, my problem is, I did not found SEARCH request on DEV targets,
> so I can not allow this request. I really need to allow this
> process to collect data correctly, but RC and ACL blocks it. Do you
> have any idea?
>
> I'm running RSBAC 1.3.8 with pre-patched kernel 2.6.24.3.

This is a bug in the filesystem object hiding code. It has been fixed 
in svn some time ago, but for now you should probably turn that 
feature off.

Amon.
--

-- 
http://www.rsbac.org - GnuPG: 2048g/5DEAAA30 2002-10-22