Jens Kasten | 19 Oct 2007 06:33
Picon

segfault by touch

hi liste,

i use the gentoo hardened with kernel 2.6.22.9 with pax and rsbac.
yesterday i get an update from glib i think and now,
when i do use touch i get a kill the process

Oct 19 02:28:36 jaschtschik Unable to handle kernel paging request at
00000000000102ae RIP:
Oct 19 02:28:36 jaschtschik [<ffffffff802348eb>] rsbac_get_parent+0x6c/0x12e
Oct 19 02:28:36 jaschtschik PGD 0
Oct 19 02:28:36 jaschtschik Oops: 0000 [79] SMP
Oct 19 02:28:36 jaschtschik CPU 1
Oct 19 02:28:36 jaschtschik Pid: 1790, comm: touch Not tainted
2.6.22.9-rsbac-0.05 #1
Oct 19 02:28:36 jaschtschik RIP: 0010:[<ffffffff802348eb>] 
[<ffffffff802348eb>] rsbac_get_parent+0x6c/0x12e
Oct 19 02:28:36 jaschtschik RSP: 0018:ffff810013525908  EFLAGS: 00010202
Oct 19 02:28:36 jaschtschik RAX: 0000000000010246 RBX: ffff810013525a98
RCX: 00000000fffffc0f
Oct 19 02:28:36 jaschtschik RDX: ffff810013525f58 RSI: ffff810013525a04
RDI: 0000000000000000
Oct 19 02:28:36 jaschtschik RBP: ffff810013525cb8 R08: ffff81003e1d7840
R09: 0000000000000001
Oct 19 02:28:36 jaschtschik R10: 00000000000006fe R11: 0000000000000246
R12: ffff81003e1d7840
Oct 19 02:28:36 jaschtschik R13: ffff810013525b38 R14: 0000000000000000
R15: 0000000000000000
Oct 19 02:28:36 jaschtschik FS:  000036a31159fb00(0000)
GS:ffff81003f04fbc0(0000) knlGS:0000000000000000
Oct 19 02:28:36 jaschtschik CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
(Continue reading)

1-IT-4-HOSP | 26 Oct 2007 15:08
Picon

RC Problem with klog and syslogd

Hi list,

I'm using a Debian Lenny,
vanilla kernel 2.6.22.1,
patch-linux-2.6.22.1-rsbac-1.3.5,
rsbac-common-1.3.5
rsbac-admin-1.3.5

I've activated softmode to configure RSBAC. Since the first boot I've 
the problem that the klod and syslogd interrupt each other so I get tons 
of messages (about 250 per second) like these:

Oct 25 18:07:33 lenny kernel: 0000200341|rsbac_adf_request(): request 
SEND, pid 1985, ppid 1, prog_name klogd, prog_file /sbin/klogd, uid 0, 
target_type UNIXSOCK, tid Device 00:14 Inode 6049 Path /log, attr 
process, value 1975, result NOT_GRANTED (Softmode) by RC

Oct 25 18:07:33 lenny kernel: 0000200342|rsbac_adf_request(): request 
RECEIVE, pid 1975, ppid 1, prog_name syslogd, prog_file /sbin/syslogd, 
uid 0, target_type UNIXSOCK, tid Device 00:14 Inode 6049 Path /log, attr 
process, value 1975, result NOT_GRANTED (Softmode) by RC

So I "killall klogd" to work on the  system and try to allow the klogd.
I used 
http://www.rsbac.org/wiki/experiences/telmich#configuring_bind9_dns_server 
as example, because there was a "RC-Problem" too.

-> rsbac_rc_role_menu -> new role (with new id and name) -> Type Menu -> 
and now I see the problem. My target_type is UNIXSOCK and I can't choose 
anything like that. Nevertheless I tried it with the FD-Type (and 
(Continue reading)

Amon Ott | 27 Oct 2007 18:47

Re: RC Problem with klog and syslogd

On Friday 26 October 2007 15:08, 1-IT-4-HOSP wrote:
> I've activated softmode to configure RSBAC. Since the first boot
> I've the problem that the klod and syslogd interrupt each other so
> I get tons of messages (about 250 per second) like these:
>
> Oct 25 18:07:33 lenny kernel: 0000200341|rsbac_adf_request():
> request SEND, pid 1985, ppid 1, prog_name klogd, prog_file
> /sbin/klogd, uid 0, target_type UNIXSOCK, tid Device 00:14 Inode
> 6049 Path /log, attr process, value 1975, result NOT_GRANTED
> (Softmode) by RC
>
> Oct 25 18:07:33 lenny kernel: 0000200342|rsbac_adf_request():
> request RECEIVE, pid 1975, ppid 1, prog_name syslogd, prog_file
> /sbin/syslogd, uid 0, target_type UNIXSOCK, tid Device 00:14 Inode
> 6049 Path /log, attr process, value 1975, result NOT_GRANTED
> (Softmode) by RC

So klogd (pid 1985) sends data to syslogd (pid 1975) through Unix 
socket /dev. Two things that look wrong:

- Path should usually be /dev/log (is /log correct in your system?)
- The RECEIVE request should show the other process 1985 as partner 
process (value of attribute "process"). This may be caused by 
sys_sendto, where the receiver does not see the sender's pid.

> So I "killall klogd" to work on the  system and try to allow the
> klogd. I used
> http://www.rsbac.org/wiki/experiences/telmich#configuring_bind9_dns
>_server as example, because there was a "RC-Problem" too.
>
(Continue reading)

Amon Ott | 30 Oct 2007 17:46

Re: RC Problem with klog and syslogd

On Tuesday 30 October 2007 16:52, 1-IT-4-HOSP wrote:
> Amon Ott schrieb Am 27.10.2007 18:47:
> > So klogd (pid 1985) sends data to syslogd (pid 1975) through Unix
> > socket /dev. Two things that look wrong:
> >
> > - Path should usually be /dev/log (is /log correct in your
> > system?) - The RECEIVE request should show the other process 1985
> > as partner process (value of attribute "process"). This may be
> > caused by sys_sendto, where the receiver does not see the
> > sender's pid.
>
> "/log" is _not_ correct in my system. It's the default directory
> "/dev/log" and I don't see the reason why the messages says "/log".
> I tried to start "syslogd" with the parameter "-p /dev/log" to
> force "syslogd" to use "/dev/log", no changes.
> Then I tried "strace -f syslogd", but it says that it uses
> "/dev/log" (than it's unlinked by the -p parameter and again set to
> "/dev/log"), so that looks right for me.

This means that the RSBAC inheritance code does not work correctly. 
What filesystem type is /dev? What exact kernel sources do you use?

> > Depending on your setup, klogd's and syslogd's role are either
> > 999999 (boot role) or 2 (root's role). The RC type of /log is 0
> > by default.
>
> Which "setup" do you mean? The "make menuconfig" before compiling?

Your role configuration, and whether there is a setuid(0) somewhere in 
the init chain, which changes the role from 999999 to 2.
(Continue reading)

1-IT-4-HOSP | 30 Oct 2007 16:52
Picon

Re: RC Problem with klog and syslogd

Hi,

Amon Ott schrieb Am 27.10.2007 18:47:
> So klogd (pid 1985) sends data to syslogd (pid 1975) through Unix 
> socket /dev. Two things that look wrong:
>
> - Path should usually be /dev/log (is /log correct in your system?)
> - The RECEIVE request should show the other process 1985 as partner 
> process (value of attribute "process"). This may be caused by 
> sys_sendto, where the receiver does not see the sender's pid.
>   
"/log" is _not_ correct in my system. It's the default directory 
"/dev/log" and I don't see the reason why the messages says "/log".
I tried to start "syslogd" with the parameter "-p /dev/log" to force 
"syslogd" to use "/dev/log", no changes.
Then I tried "strace -f syslogd", but it says that it uses "/dev/log" 
(than it's unlinked by the -p parameter and again set to "/dev/log"), so 
that looks right for me.
> First of all, you should enable RC debugging to see the exact role and 
> type involved. Either use rsbac_debug_adf_rc kernel parameter, or as 
> user 400 (secoff) call:
>
> echo debug_adf_rc 1 >/proc/rsbac-info/debug
>   
done.
> Depending on your setup, klogd's and syslogd's role are either 999999 
> (boot role) or 2 (root's role). The RC type of /log is 0 by default.
>   
Which "setup" do you mean? The "make menuconfig" before compiling?
> Let us assume the role is 2. Then as user 400 call
(Continue reading)

Javier Martínez | 30 Oct 2007 17:17
Picon

Re: RC Problem with klog and syslogd

>
> Oct 30 16:55:26 rsbac-etch kernel: 0000023807|check_comp_rc(): pid 1786
> (syslogd), owner 0, rc_role 4, PROCESS rc_type 0, request RECEIVE ->
> NOT_GRANTED!
>
> Oct 30 16:55:26 rsbac-etch kernel: 0000023808|rsbac_adf_request():
> request RECEIVE, pid 1786, ppid 1, prog_name syslogd, prog_file
> /sbin/syslogd, uid 0, target_type UNIXSOCK, tid Device 00:14 Inode 4838
> Path /log, attr process, value 1786, result NOT_GRANTED (Softmode) by RC
>
Here appears that syslogd runs with role 4, probably you should grant
RECEIVE and all neededs rights to role 0 for PROCESS rc_type 0
Javier Martínez | 30 Oct 2007 17:18
Picon

Re: RC Problem with klog and syslogd

> Here appears that syslogd runs with role 4, probably you should grant
> RECEIVE and all neededs rights to role 0 for PROCESS rc_type 0
>
hmm, mistake sorry, to role 4 for PROCESS rc_type 0...
1-IT-4-HOSP | 31 Oct 2007 11:29
Picon

Re: RC Problem with klog and syslogd

Amon Ott schrieb Am 30.10.2007 17:46:
> This means that the RSBAC inheritance code does not work correctly. 
> What filesystem type is /dev? What exact kernel sources do you use?
>   
Filesystem is udev on /dev type tmpfs.
Kernel is 2.6.22.1 from kernel.org with 
"patch-linux-2.6.22.1-rsbac-1.3.5", "rsbac-common-1.3.5" and 
"rsbac-admin-1.3.5"
> Here we come to the clue: You enabled "Check partner process" in the 
> kernel config. You need to allow RECEIVE for role 4 to PROCESS type 0 
> (type_comp_process).
> This is what comes as a result. With the partner process check, there 
> are actually two requests in one.
>   
You're completely right! With this permission it works fine. Thank you 
very much :-)
Should I disable "Check partner process" with the next version I compile?

Dustin
Amon Ott | 31 Oct 2007 11:56

Re: RC Problem with klog and syslogd

On Wednesday 31 October 2007 11:29, 1-IT-4-HOSP wrote:
> Amon Ott schrieb Am 30.10.2007 17:46:
> > This means that the RSBAC inheritance code does not work
> > correctly. What filesystem type is /dev? What exact kernel
> > sources do you use?
>
> Filesystem is udev on /dev type tmpfs.
> Kernel is 2.6.22.1 from kernel.org with
> "patch-linux-2.6.22.1-rsbac-1.3.5", "rsbac-common-1.3.5" and
> "rsbac-admin-1.3.5"

Can you please retry with 
http://download.rsbac.org/kernels/1.3.6/2.6.23.1/linux-2.6.23.1-rsbac-1.3.6.tar.bz2 ?

> > Here we come to the clue: You enabled "Check partner process" in
> > the kernel config. You need to allow RECEIVE for role 4 to
> > PROCESS type 0 (type_comp_process).
> > This is what comes as a result. With the partner process check,
> > there are actually two requests in one.
>
> You're completely right! With this permission it works fine. Thank
> you very much :-)
> Should I disable "Check partner process" with the next version I
> compile?

These extra checks are fine, if you want better separation. Just keep 
in mind that more rights have to be given.

Amon.
--

-- 
(Continue reading)


Gmane