I am submitting this report to this list for documentation, perspectives
and, hopefully, helpful assistance towards resolving this issue. Sorry
in advance for the length of this post.

First reported to the Unofficial Wiki + Bugzilla of the ATI fglrx
binary, then to AMD/ATI technical support was the following issue:

I have the following configuration:
* Lenovo Thinkpad T60p
* ATI Mobility FireGL V5250 graphics card
* version 8.52.3 of the fglrx module
* Fedora 8 running version 2.6.25.14-69.fc8 of the GNU/Linux kernel

*NOTE: I have upgraded the kernel and driver from the first indications
of the problem; hence, older versions are in the bug report below.
However, the same bug persists according to both symptoms and to the
security log.

At intermittent start-ups of the X server using the fglrx driver the X
server does not display due to a security compatibility problem between
the fglrx driver and the secure SELinux module of the GNU/linux kernel.
The following is the report from the system log outlining the problem:

SELinux: out of range capability -157851600
------------[ cut here ]------------
kernel BUG at security/selinux/hooks.c:1332!
invalid opcode: 0000 [#1] SMP
Modules linked in: ipv6 snd_hda_intel snd_seq_dummy snd_seq_oss arc4
snd_seq_midi_event snd_seq ecb snd_seq_device crypto_blkcipher
snd_pcm_oss snd_mixer_oss snd_pcm i2c_i801 iwl3945 iTCO_wdt battery
iTCO_vendor_support snd_timer i2c_core ac mac80211 video thinkpad_acpi
bay snd_page_alloc irda output snd_hwdep e1000e button snd cfg80211
crc_ccitt fglrx(P)(U) pcspkr hwmon soundcore sr_mod cdrom sg usb_storage
ata_piix dm_snapshot dm_zero dm_mirror dm_mod ahci libata sd_mod
scsi_mod ext3 jbd mbcache uhci_hcd ohci_hcd ehci_hcd [last unloaded:
scsi_wait_scan]

Pid: 1488, comm: Xorg Tainted: P (2.6.25.6-27.fc8 #1)
EIP: 0060:[<c04cd328>] EFLAGS: 00213246 CPU: 1
EIP is at task_has_capability+0x46/0x79
EAX: 00000030 EBX: f6976030 ECX: 00203046 EDX: 00203046
ESI: f685f200 EDI: f6959eb0 EBP: f6959ebc ESP: f6959e6c
DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068
Process Xorg (pid: 1488, ti=f6959000 task=f6f98000 task.ti=f6959000)
Stack: c06d780d f6976030 f6f98000 00000003 f6f98000 f6976030 00000000
00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 f6976030 f6f98000 f69ca000 f6959ecc c04cd37a f6f98000 f9678400
Call Trace:
[<c04cd37a>] ? selinux_capable+0x1f/0x23
[<c04c973d>] ? security_capable+0xc/0xe
[<c042ca37>] ? __capable+0xb/0x1f
[<f954e670>] ? firegl_version+0x0/0x1b0 [fglrx]
[<c042ca5b>] ? capable+0x10/0x12
[<f954e537>] ? firegl_ioctl+0xe7/0x220 [fglrx]
[<c046e370>] ? handle_mm_fault+0x64f/0x6ef
[<f9543c80>] ? ip_firegl_ioctl+0xe/0x10 [fglrx]
[<c048ad76>] ? vfs_ioctl+0x4e/0x67
[<c048aff1>] ? do_vfs_ioctl+0x262/0x279
[<c04d0226>] ? selinux_file_ioctl+0xa8/0xab
[<c048b048>] ? sys_ioctl+0x40/0x5c
[<c0405b7e>] ? syscall_call+0x7/0xb
=======================
Code: 05 00 00 89 d0 f3 ab 8b 4d b8 89 d8 b2 04 c1 f8 05 c6 45 bc 03 89
5d c4 89 4d c0 74 19 48 74 11 53 68 0d 78 6d c0 e8 6d 9e f5 ff <0f> 0b
58 5a eb fe ba 45 00 00 00 8b 46 08 83 e3 1f 0f b7 f2 8d
EIP: [<c04cd328>] task_has_capability+0x46/0x79 SS:ESP 0068:f6959e6c
---[ end trace 93d33da5bd859df0 ]---
[fglrx:firegl_release] *ERROR* device busy: 1 0
[fglrx] release failed with code -EBUSY

-------------------- End of report -------------------

AMD/ATI's response is as follows:


I regret there is no support for Linux at this time.

Please see the following

737-28027: LINUX support for ATI Video cards




LINUX support for ATI Video cards:

Although we have drivers for Linux posted on the ATI website, we
do not provide technical support for driver or multimedia issues
in Linux directly.

The Linux drivers available (For laptops, RADEON and All in
wonder Products) from AMD are provided are "as is".

If you are looking for drivers then go to:
http://ati.amd.com/support/driver.html

For information regarding the ATI Proprietary Linux Driver
visit: http://www.ati.com/products/catalyst/linux.html

Our web site offers several links to Linux support websites that
may help you.

The link below has information that might be helpful to your
case.

http://wiki.cchtml.com/index.php/Main_Page

There are also very good articles from third parties:

1. http://www.rage3d.com/content/articles/atilinuxhowto/Linux_ATI.html#SECTION000140000000000000000
2. http://www.linux.org/help/index.html
3. http://www.linuxdoc.org/
4. http://www.xfree86.org/

To report issues with Linux drivers you can submit an online
ticket using the “Linux Driver Feedback� category, and your
report will be received and reviewed/tested by our driver team.
Please note that your report will only be responded to if we
require additional information. We do not respond to all support
inquires.

For the Linux Driver Feedback submission page, visit.

http://support.ati.com/ics/survey/survey.asp?deptID=894&surveyID=508&type=web

---------------- End of response -----------------

I could disable SELinux and I would not have this problem; however, I
was hoping that there was a much secure or safer work-around to this
problem.

Peace,
Frank



--
fedora-selinux-list mailing list
fedora-selinux-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-selinux-list

On Thu, 2008-09-25 at 14:15 +1000, James Morris wrote:
> On Wed, 24 Sep 2008, Francis K Shim wrote:
>
> >
> > I could disable SELinux and I would not have this problem; however, I
> > was hoping that there was a much secure or safer work-around to this
> > problem.
>
> The video driver is inherently dangerous, so the safe approach is not to
> use it.

James isn't exactly being helpful, but the reason is because as you
guessed the problem lies squarely and obviously with AMD/ATI and there
isn't much we can do to help with closed source proprietary software.
AMD/ATI is obviously doing it wrong and when it comes to security doing
it wrong is never a good idea. Sadly we don't have their source so I
can't show you the line of code (or do anything to fix it), but your
backtrace should make it pretty obvious if anyone inside ATI decides to
care.

Stephen James, what do the two of you think about something like this?
Maybe a WARN_ONCE() ?

security/selinux/hooks.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c
index 03fc6a8..14f1242 100644
--- a/security/selinux/hooks.c
+++ b/security/selinux/hooks.c
@@ -1385,7 +1385,8 @@ static int task_has_capability(struct task_struct *tsk,
default:
printk(KERN_ERR
"SELinux: out of range capability %d
", cap);
- BUG();
+ WARN();
+ return -EPERM;
}
return avc_has_perm(tsec->sid, tsec->sid, sclass, av, &ad);
}


--
fedora-selinux-list mailing list
fedora-selinux-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-selinux-list

On Thu, 2008-09-25 at 09:13 -0400, Eric Paris wrote:
> On Thu, 2008-09-25 at 14:15 +1000, James Morris wrote:
> > On Wed, 24 Sep 2008, Francis K Shim wrote:
> >
> > >
> > > I could disable SELinux and I would not have this problem; however, I
> > > was hoping that there was a much secure or safer work-around to this
> > > problem.
> >
> > The video driver is inherently dangerous, so the safe approach is not to
> > use it.
>
> James isn't exactly being helpful, but the reason is because as you
> guessed the problem lies squarely and obviously with AMD/ATI and there
> isn't much we can do to help with closed source proprietary software.
> AMD/ATI is obviously doing it wrong and when it comes to security doing
> it wrong is never a good idea. Sadly we don't have their source so I
> can't show you the line of code (or do anything to fix it), but your
> backtrace should make it pretty obvious if anyone inside ATI decides to
> care.
>
> Stephen James, what do the two of you think about something like this?
> Maybe a WARN_ONCE() ?

Maybe instead of returning -EPERM unconditionally, returning based on
the unknown_perms setting? Of course what to do if its set to reject
would be a question (my suggestion would be deny on that too).

> security/selinux/hooks.c | 3 ++-
> 1 files changed, 2 insertions(+), 1 deletions(-)
>
> diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c
> index 03fc6a8..14f1242 100644
> --- a/security/selinux/hooks.c
> +++ b/security/selinux/hooks.c
> @@ -1385,7 +1385,8 @@ static int task_has_capability(struct task_struct *tsk,
> default:
> printk(KERN_ERR
> "SELinux: out of range capability %d
", cap);
> - BUG();
> + WARN();
> + return -EPERM;
> }
> return avc_has_perm(tsec->sid, tsec->sid, sclass, av, &ad);
> }
>
>
> --
> fedora-selinux-list mailing list
> fedora-selinux-list@redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-selinux-list
--
Chris PeBenito
Tresys Technology, LLC
(410) 290-1411 x150

--
fedora-selinux-list mailing list
fedora-selinux-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-selinux-list

On Fri, 26 Sep 2008 00:31:09 +1000, James Morris said:

> - Francis asked for a much-secure or safer workaround to the issue.
> Given that the driver is messing with kernel security, is also broken in
> its use of a security API, and not maintained, I'm certainly not going to
> recommend its continued use in this context.

Given the fact it's a kernel BUG, I wonder if the *real* issue isn't
that the driver doesn't support SELinux, but that it doesn't understand
the expanded more-than-32-bits capabilities in recent kernels, causing
something to overlay something it shouldn't have...
--
fedora-selinux-list mailing list
fedora-selinux-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-selinux-list

On Thu, 2008-09-25 at 23:38 -0400, Valdis.Kletnieks@vt.edu wrote:
> On Fri, 26 Sep 2008 00:31:09 +1000, James Morris said:
>
> > - Francis asked for a much-secure or safer workaround to the issue.
> > Given that the driver is messing with kernel security, is also broken in
> > its use of a security API, and not maintained, I'm certainly not going to
> > recommend its continued use in this context.

>From the perspective of security and safety, I agree with James in
simply *not* using the fglrx driver, in favor of a VESA or compatible
open-source device driver; however, that being said, it will essentially
cripple the usage of the full range of the video card's capabilities.
It is acceptable if I were to only be limited to simple text editing and
low intensity graphics. However, it does mean that any photo-realistic
and intense graphics manipulation will suffer, which I can live with for
a little while, but not forever.

> Given the fact it's a kernel BUG, I wonder if the *real* issue isn't
> that the driver doesn't support SELinux, but that it doesn't understand
> the expanded more-than-32-bits capabilities in recent kernels, causing
> something to overlay something it shouldn't have...

If this is the case, then I would be happy to tell AMD/ATI about this
interface bug; however, I think that SELinux itself, Linux and the
Open-source community should use incidences like this as further
proof-of-application (versus proof-of-concept). At least, in this
respect, there should be an opportunity for strengthening liason between
*us* and the AMD/ATI team.

Peace,
Frank


--
fedora-selinux-list mailing list
fedora-selinux-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-selinux-list

On Thu, 2008-09-25 at 09:13 -0400, Eric Paris wrote:
> On Thu, 2008-09-25 at 14:15 +1000, James Morris wrote:
> > On Wed, 24 Sep 2008, Francis K Shim wrote:
> >
> > >
> > > I could disable SELinux and I would not have this problem; however, I
> > > was hoping that there was a much secure or safer work-around to this
> > > problem.
> >
> > The video driver is inherently dangerous, so the safe approach is not to
> > use it.
>
> James isn't exactly being helpful, but the reason is because as you
> guessed the problem lies squarely and obviously with AMD/ATI and there
> isn't much we can do to help with closed source proprietary software.
> AMD/ATI is obviously doing it wrong and when it comes to security doing
> it wrong is never a good idea. Sadly we don't have their source so I
> can't show you the line of code (or do anything to fix it), but your
> backtrace should make it pretty obvious if anyone inside ATI decides to
> care.
>
> Stephen James, what do the two of you think about something like this?
> Maybe a WARN_ONCE() ?
>
> security/selinux/hooks.c | 3 ++-
> 1 files changed, 2 insertions(+), 1 deletions(-)
>
> diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c
> index 03fc6a8..14f1242 100644
> --- a/security/selinux/hooks.c
> +++ b/security/selinux/hooks.c
> @@ -1385,7 +1385,8 @@ static int task_has_capability(struct task_struct *tsk,
> default:
> printk(KERN_ERR
> "SELinux: out of range capability %d
", cap);
> - BUG();
> + WARN();
> + return -EPERM;
> }
> return avc_has_perm(tsec->sid, tsec->sid, sclass, av, &ad);
> }

I'm not opposed to changing it to an error return, although I'm not
clear that will help.

Does anyone know what the driver is actually trying to do here? The
message said:
SELinux: out of range capability -157851600
and -157851600 == 0xf6976030
Obviously that isn't what they meant to pass to capable().

--
Stephen Smalley
National Security Agency

--
fedora-selinux-list mailing list
fedora-selinux-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-selinux-list

On Mon, 2008-09-29 at 09:13 -0400, Stephen Smalley wrote:
> On Thu, 2008-09-25 at 09:13 -0400, Eric Paris wrote:
> > On Thu, 2008-09-25 at 14:15 +1000, James Morris wrote:
> > > On Wed, 24 Sep 2008, Francis K Shim wrote:
> > >
> > > >
> > > > I could disable SELinux and I would not have this problem; however, I
> > > > was hoping that there was a much secure or safer work-around to this
> > > > problem.
> > >
> > > The video driver is inherently dangerous, so the safe approach is not to
> > > use it.
> >
> > James isn't exactly being helpful, but the reason is because as you
> > guessed the problem lies squarely and obviously with AMD/ATI and there
> > isn't much we can do to help with closed source proprietary software.
> > AMD/ATI is obviously doing it wrong and when it comes to security doing
> > it wrong is never a good idea. Sadly we don't have their source so I
> > can't show you the line of code (or do anything to fix it), but your
> > backtrace should make it pretty obvious if anyone inside ATI decides to
> > care.
> >
> > Stephen James, what do the two of you think about something like this?
> > Maybe a WARN_ONCE() ?
> >
> > security/selinux/hooks.c | 3 ++-
> > 1 files changed, 2 insertions(+), 1 deletions(-)
> >
> > diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c
> > index 03fc6a8..14f1242 100644
> > --- a/security/selinux/hooks.c
> > +++ b/security/selinux/hooks.c
> > @@ -1385,7 +1385,8 @@ static int task_has_capability(struct task_struct *tsk,
> > default:
> > printk(KERN_ERR
> > "SELinux: out of range capability %d
", cap);
> > - BUG();
> > + WARN();
> > + return -EPERM;
> > }
> > return avc_has_perm(tsec->sid, tsec->sid, sclass, av, &ad);
> > }
>
> I'm not opposed to changing it to an error return, although I'm not
> clear that will help.
>
> Does anyone know what the driver is actually trying to do here? The
> message said:
> SELinux: out of range capability -157851600
> and -157851600 == 0xf6976030
> Obviously that isn't what they meant to pass to capable().

I don't think any of us have any idea what the driver was trying to do
here, but clearly they are doing it wrong. Maybe you can turn on your
NSA brain reading satellite and peer into the brain of an ATI
programmer....

I'm actually quite shocked it didn't blow up in cap_raised

#define cap_raised(c, flag) ((c).cap[CAP_TO_INDEX(flag)] & CAP_TO_MASK(flag))

its just got to be darn lucky that c.cap[huge index] actually hit a
legal spot of memory and didn't bug on a pagefault right there. (I'm
pretty sure 64 bit capabilities were in 2.6.25 right?) Before 64 bit
caps I don't think we had the array index and only had the mask, so
something huge wouldn't explode in the cap code...

We can turn this into a WARN_ONCE() but people with this driver would
still be taking a walk on the wild side since there is no bounds
checking what-so-ever in the cap code....

I feel your pain, and we can make the kernel stop BUGing in SELinux
code, but after looking at the cap code that it already ran your just as
likely to BUG even without SELinux (and not nearly as cleanly...)

I'm sorry to say I think its probably best for us to leave the BUG so at
least the kernel will explode predictably rather than randomly and in a
harder to track down way...

I wonder if I should propose adding a cap_valid() check to cap_capable()
upstream...

-Eric

--
fedora-selinux-list mailing list
fedora-selinux-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-selinux-list

On Mon, 2008-09-29 at 09:31 -0400, Eric Paris wrote:

> I wonder if I should propose adding a cap_valid() check to cap_capable()
> upstream...

Couple minutes on kernelopps.org showed that almost 3000 others had this
same problem. So anyway, the problem is absolutely in the firegl code
but I did propose something upstream to try to hopefully keep people's
computers alive. We'll see what the comments are....

http://marc.info/?l=linux-kernel&m=122278342811993&w=2

-Eric

--
fedora-selinux-list mailing list
fedora-selinux-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-selinux-list

Thanks for the further information.

Eric, I hope you do not mind, but I forwarded this information to the
AMD/ATI technical support using their ticket system.

I am hoping that somehow a light-bulb will actually go off among the
"customer technical support" crew to actually forward this and past
information to their actual coders/programmers.

Peace,
Frank

On Tue, 2008-09-30 at 10:08 -0400, Eric Paris wrote:
> 2

--
fedora-selinux-list mailing list
fedora-selinux-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-selinux-list