[Fwd: [Fedora8] SElinux bug]

[max bianco]

On Thu, Jun 12, 2008 at 12:32 PM, Stephen Smalley <sds at tycho.nsa.gov> wrote:
>
> On Thu, 2008-06-12 at 11:03 -0400, max wrote:
>> Found on fedora list.
>>
>> -------- Original Message --------
>> Subject: [Fedora8] SElinux bug
>> Date: Thu, 12 Jun 2008 15:58:58 +0100
>> From: hicham <hichamlinux at gmail.com>
>> Reply-To: For users of Fedora <fedora-list at redhat.com>
>> To: For users of Fedora <fedora-list at redhat.com>
>>
>> Hello
>> I had this morning a "freeze", where I could not shutdown X server or
>> the laptop properly, looking at /var/log/messages:
>> I found what I suspect a selinux bug :
>>
>> Jun 12 12:19:00 laptop kernel: SELinux:  out of range capability -555425744
>
> That's not a bug in SELinux, but rather in the caller - passing an
> illegal value to capable().
>
>> Jun 12 12:19:00 laptop kernel: ------------[ cut here ]------------
>> Jun 12 12:19:00 laptop kernel: kernel BUG at security/selinux/hooks.c:1332!
>> Jun 12 12:19:00 laptop kernel: invalid opcode: 0000 [#1] SMP
>> Jun 12 12:19:00 laptop kernel: Modules linked in: iptable_nat xt_limit
>> xt_tcpudp iptable_mangle ipt_LOG ipt_MASQUERADE nf_nat xt_DSCP
>> ipt_REJE
>> CT nf_conntrack_irc nf_conntrack_ftp nf_conntrack_ipv4 xt_state
>> nf_conntrack iptable_filter ip_tables x_tables pppoatm pppoe pppox
>> ppp_synctty
>>   ppp_async ppp_generic slhc appletalk ipx p8023 ipv6 cpufreq_ondemand
>> acpi_cpufreq vfat fat dm_mirror dm_multipath dm_mod parport_pc
>> smsc_ircc
>> 2 parport irda crc_ccitt pcspkr floppy serio_raw snd_intel8x0
>> snd_seq_dummy snd_seq_oss video snd_seq_midi_event snd_seq output
>> snd_seq_device
>>   snd_intel8x0m fglrx(P)(U) snd_ac97_codec snd_pcm_oss ac97_bus tg3
>
> fglrx being the guilty culprit.
>

So did fglrx freeze the machine or did SELinux? if the latter is this
sort of behavior configurable in some way? What i mean is can SELinux,
be configured to respond in particular ways in the event of some
unknown or unexpected event? Say I want it to segfault in a situation
like this or kill X and drop to runlevel three, prohibit remote access
entirely or maybe all but one particular node, and send an email alert
to the administrator. I am not suggesting this behavior for the
average desktop but in certain environments a segfault might be
preferable to a potential compromise. Though I am sure false alarms
would cause quite a few grumbles not to mention soiled pants.
-- 
I am altering the deal. Pray I do not alter it any further. --Darth Vader