3:10 p.m.
On Sam 10 décembre 2005 21:59, Nicolas Mailhot wrote:
On Sam 10 décembre 2005 21:37, Ulrich Drepper wrote:
> Nicolas Mailhot wrote:
>> avc: denied { execmem } for pid=2950 comm="thunderbird-bin"
>> scontext=user_u:system_r:unconfined_t:s0-s0:c0.c255
>> tcontext=user_u:system_r:unconfined_t:s0-s0:c0.c255 tclass=process
>
> If this really happens then this is a terrible bug in tbird. It's
> nothing which should be patched with the policy. By not adding the
> support to catch these problems early the code won't be fixed.
>
> New rules are often added for a specific purpose: discover bugs in
> programs and stop existing threats. It would be wrong to not attack
> these as soon as possible.
It really happens, at least there (and thunderbird hasn't been updated,
only selinux was - so it was happening before).
So there are lots of work to do with existing rules before even thinking
of moving to new bits like httpd port policy.
Vanilla x86_64 thunderbird (thunderbird-1.5-0.5.1.rc1) (installed a week
ago when evo started dying on no ascii folders), only extension : enigmail
0.93.1 (not that it actually works)
Rawhide killed evo a week ago (#174931)
It killed thunderbird today
I'm running out of imap clients. I still have squirrelmail, and it's not
even the rawhide one, since that one started misbehaving at least a month
before (#162852)
Do you want a bug entry for this problem too ?
Regards,
--
Nicolas Mailhot
3:44 p.m.
New subject: Adding two new booleans to httpd to tighten it's security.
Nicolas Mailhot wrote:
Rawhide killed evo a week ago (#174931)
It killed thunderbird today
I'm running out of imap clients.
Just add appropriate security labels.
for f in /usr/lib/thunderbird-1.5/*.so /usr/lib/thunderbird-1.5/*/*.so;
do if readelf -d $f | fgrep -q TEXTREL; then chcon
system_u:object_r:texrel_shlib_t $f; fi; done
(One long line.) Repeat for other directories.
This specific problem is a gcc bug.
--
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
3:50 p.m.
New subject: Adding two new booleans to httpd to tighten it's security.
On Sam 10 décembre 2005 22:44, Ulrich Drepper wrote:
Nicolas Mailhot wrote:
> Rawhide killed evo a week ago (#174931)
> It killed thunderbird today
> I'm running out of imap clients.
Just add appropriate security labels.
for f in /usr/lib/thunderbird-1.5/*.so /usr/lib/thunderbird-1.5/*/*.so;
do if readelf -d $f | fgrep -q TEXTREL; then chcon
system_u:object_r:texrel_shlib_t $f; fi; done
(One long line.) Repeat for other directories.
This specific problem is a gcc bug.
Ok, thanks.
I won't do it because workarounding like this is a slippery slope ending
with selinux=false. I try to keep my system in line with current rawhide
so it stays a valid test system (even if sometimes it's a difficult
position to keep)
But thank you for the information.
--
Nicolas Mailhot
3:35 p.m.
New subject: Adding two new booleans to httpd to tighten it's security.
Running latest rawhide stuff, targeted/enforcing.
Two 'after market' packages appear to need some help: skype and vmware.
Here's the avc from vmware
----
time->Sun Dec 11 13:05:51 2005
type=AVC_PATH msg=audit(1134335151.660:39):
path="/usr/lib/vmware/lib/libgdk-x11-2.0.so.0/libgdk-x11-2.0.so.0"
type=SYSCALL msg=audit(1134335151.660:39): arch=40000003 syscall=125 per=400000
success=no exit=-13 a0=b7c99000 a1=7b000 a2=5 a3=bfc5a1e0 items=0
pid=4418 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0
sgid=0 fsgid=0 comm="vmware" exe="/usr/lib/vmware/bin/vmware"
type=AVC msg=audit(1134335151.660:39): avc: denied { execmod } for
pid=4418 comm="vmware" name="libgdk-x11-2.0.so.0" dev=dm-0 ino=343461
scontext=root:system_r:unconfined_t:s0-s0:c0.c255
tcontext=system_u:object_r:lib_t:s0 tclass=file
Looks like they have a 'local version' of libgdk-x11-2.s0.0 that needs
TEXTREL (looks like the one in /usr/lib doesn't need TEXTREL).
and for skype:
----
time->Sun Dec 11 12:00:29 2005
type=PATH msg=audit(1134331229.904:20): item=1 flags=101 inode=327136
dev=fd:00 mode=0100755 ouid=0 ogid=0 rdev=00:00
type=PATH msg=audit(1134331229.904:20): item=0 name="/usr/bin/skype"
flags=101 inode=145190 dev=fd:00 mode=0100755 ouid=0 ogid=0 rdev=00:00
type=CWD msg=audit(1134331229.904:20): cwd="/home/tbl"
type=SYSCALL msg=audit(1134331229.904:20): arch=40000003 syscall=11
success=yes exit=0 a0=86ec0d8 a1=86f0e98 a2=86eca28 a3=1 items=2
pid=3359 auid=4294967295 uid=500 gid=500 euid=500 suid=500 fsuid=500
egid=500 sgid=500 fsgid=500 comm="skype"
type=AVC msg=audit(1134331229.904:20): avc: denied { execmem } for
pid=3359 comm="skype" scontext=user_u:system_r:unconfined_t:s0
tcontext=user_u:system_r:unconfined_t:s0 tclass=process
----
I'm willing to pester the vmware folks to get them to examine/fix
this. Not sure how to do that with the skype folks .....
Any suggestions with either?
tom
--
Tom London
3:52 p.m.
New subject: Adding two new booleans to httpd to tighten it's security.
On Dim 11 décembre 2005 22:35, Tom London wrote:
Running latest rawhide stuff, targeted/enforcing.
Two 'after market' packages appear to need some help: skype and vmware.
Seems some python bits and mplayer are not safe either :
type=AVC msg=audit(1134326070.107:1325): avc: denied { execmem } for
pid=28368 comm="mplayer"
scontext=user_u:system_r:unconfined_t:s0-s0:c0.c255
tcontext=user_u:system_r:unconfined_t:s0-s0:c0.c255 tclass=process
type=SYSCALL msg=audit(1134326070.107:1325): arch=c000003e syscall=10
success=no exit=-13 a0=7fffff8a5000 a1=1000 a2=1000007 a3=1 items=0
pid=28368 auid=4294967295 uid=500 gid=500 euid=500 suid=500 fsuid=500
egid=500 sgid=500 fsgid=500 comm="mplayer" exe="/usr/bin/mplayer"
type=AVC msg=audit(1134326066.831:1324): avc: denied { execmem } for
pid=28361 comm="python"
scontext=user_u:system_r:unconfined_t:s0-s0:c0.c255
tcontext=user_u:system_r:unconfined_t:s0-s0:c0.c255 tclass=process
type=SYSCALL msg=audit(1134326066.831:1324): arch=c000003e syscall=10
success=no exit=-13 a0=7fffff863000 a1=1000 a2=1000007 a3=1 items=0
pid=28361 auid=4294967295 uid=500 gid=500 euid=500 suid=500 fsuid=500
egid=500 sgid=500 fsgid=500 comm="python" exe="/usr/bin/python"
Oh, well I didn't have a http://bugzilla.livna.org/ account yet
Regards,
--
Nicolas Mailhot
4:24 p.m.
New subject: Adding two new booleans to httpd to tighten it's security.
Nicolas Mailhot wrote:
Seems some python bits and mplayer are not safe either :
You have to specify which architecture. I assume the following are x64
since otherwise syscall=10 makes no sense.
type=AVC msg=audit(1134326070.107:1325): avc: denied { execmem }
for
pid=28368 comm="mplayer"
scontext=user_u:system_r:unconfined_t:s0-s0:c0.c255
tcontext=user_u:system_r:unconfined_t:s0-s0:c0.c255 tclass=process
type=SYSCALL msg=audit(1134326070.107:1325): arch=c000003e syscall=10
success=no exit=-13 a0=7fffff8a5000 a1=1000 a2=1000007 a3=1 items=0
pid=28368 auid=4294967295 uid=500 gid=500 euid=500 suid=500 fsuid=500
egid=500 sgid=500 fsgid=500 comm="mplayer" exe="/usr/bin/mplayer"
type=AVC msg=audit(1134326066.831:1324): avc: denied { execmem } for
pid=28361 comm="python"
scontext=user_u:system_r:unconfined_t:s0-s0:c0.c255
tcontext=user_u:system_r:unconfined_t:s0-s0:c0.c255 tclass=process
type=SYSCALL msg=audit(1134326066.831:1324): arch=c000003e syscall=10
success=no exit=-13 a0=7fffff863000 a1=1000 a2=1000007 a3=1 items=0
pid=28361 auid=4294967295 uid=500 gid=500 euid=500 suid=500 fsuid=500
egid=500 sgid=500 fsgid=500 comm="python" exe="/usr/bin/python"
Both a mprotect calls but because x64 does not allow text relocations
the reason must be in the program logic. Definitely wrong code but what
remains to be seen.
Try using strace to determine what the programs try to do.
--
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
2 p.m.
New subject: Adding two new booleans to httpd to tighten it's security.
On Dim 11 décembre 2005 23:24, Ulrich Drepper wrote:
Nicolas Mailhot wrote:
> Seems some python bits and mplayer are not safe either :
You have to specify which architecture. I assume the following are x64
since otherwise syscall=10 makes no sense.
x86_64
> type=AVC msg=audit(1134326070.107:1325): avc: denied { execmem
} for
> pid=28368 comm="mplayer"
> scontext=user_u:system_r:unconfined_t:s0-s0:c0.c255
> tcontext=user_u:system_r:unconfined_t:s0-s0:c0.c255 tclass=process
> type=SYSCALL msg=audit(1134326070.107:1325): arch=c000003e syscall=10
> success=no exit=-13 a0=7fffff8a5000 a1=1000 a2=1000007 a3=1 items=0
> pid=28368 auid=4294967295 uid=500 gid=500 euid=500 suid=500 fsuid=500
> egid=500 sgid=500 fsgid=500 comm="mplayer"
exe="/usr/bin/mplayer"
>
> type=AVC msg=audit(1134326066.831:1324): avc: denied { execmem } for
> pid=28361 comm="python"
> scontext=user_u:system_r:unconfined_t:s0-s0:c0.c255
> tcontext=user_u:system_r:unconfined_t:s0-s0:c0.c255 tclass=process
> type=SYSCALL msg=audit(1134326066.831:1324): arch=c000003e syscall=10
> success=no exit=-13 a0=7fffff863000 a1=1000 a2=1000007 a3=1 items=0
> pid=28361 auid=4294967295 uid=500 gid=500 euid=500 suid=500 fsuid=500
> egid=500 sgid=500 fsgid=500 comm="python" exe="/usr/bin/python"
Both a mprotect calls but because x64 does not allow text relocations
the reason must be in the program logic. Definitely wrong code but what
remains to be seen.
Try using strace to determine what the programs try to do.
I will try to isolate the problem. This was just a quick scan of
yesterday's audit.log. I installed a lot of new python packages at that
time, so pinpointing the problem is going to take some time.
Regards,
--
Nicolas Mailhot
4:02 p.m.
New subject: Adding two new booleans to httpd to tighten it's security.
Tom London wrote:
path="/usr/lib/vmware/lib/libgdk-x11-2.0.so.0/libgdk-x11-2.0.so.0"
type=SYSCALL msg=audit(1134335151.660:39): arch=40000003 syscall=125 per=400000
This is indeed a text relocation issue. Since the code is LGPLed they
have to provide you with the sources. Just use compile and use
eu-findtextrel to determine the sources of the text relocation.
type=PATH msg=audit(1134331229.904:20): item=0
name="/usr/bin/skype"
flags=101 inode=145190 dev=fd:00 mode=0100755 ouid=0 ogid=0 rdev=00:00
type=CWD msg=audit(1134331229.904:20): cwd="/home/tbl"
type=SYSCALL msg=audit(1134331229.904:20): arch=40000003 syscall=11
That's a fault in the execve syscall. This most likely means the binary
has a section which is executable and writable at the same time. This
really should never happen, it's a security nightmare. Would you want
an application which by its nature has to accept connections from all
over the net to have such a flaw?
Maybe you can post the output of
eu-readelf -l /usr/bin/skype
--
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
4:13 p.m.
New subject: Adding two new booleans to httpd to tighten it's security.
On 12/11/05, Ulrich Drepper <drepper(a)redhat.com> wrote:
Tom London wrote:
> path="/usr/lib/vmware/lib/libgdk-x11-2.0.so.0/libgdk-x11-2.0.so.0"
> type=SYSCALL msg=audit(1134335151.660:39): arch=40000003 syscall=125 per=400000
This is indeed a text relocation issue. Since the code is LGPLed they
have to provide you with the sources. Just use compile and use
eu-findtextrel to determine the sources of the text relocation.
> type=PATH msg=audit(1134331229.904:20): item=0 name="/usr/bin/skype"
> flags=101 inode=145190 dev=fd:00 mode=0100755 ouid=0 ogid=0 rdev=00:00
> type=CWD msg=audit(1134331229.904:20): cwd="/home/tbl"
> type=SYSCALL msg=audit(1134331229.904:20): arch=40000003 syscall=11
That's a fault in the execve syscall. This most likely means the binary
has a section which is executable and writable at the same time. This
really should never happen, it's a security nightmare. Would you want
an application which by its nature has to accept connections from all
over the net to have such a flaw?
Maybe you can post the output of
eu-readelf -l /usr/bin/skype
--
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
Agree that its a security 'accident' waiting to happen.
Here is the output of 'eu-readelf -l /usr/bin/skype'
Program Headers:
Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align
PHDR 0x000034 0x08048034 0x08048034 0x000120 0x000120 R E 0x4
INTERP 0x000154 0x08048154 0x08048154 0x000013 0x000013 R 0x1
[Requesting program interpreter: /lib/ld-linux.so.2]
LOAD 0x000000 0x08048000 0x08048000 0x7970f9 0x7970f9 RWE 0x1000
LOAD 0x7970fc 0x087e00fc 0x087e00fc 0x00bc68 0x101e44 RWE 0x1000
LOAD 0x7a2d64 0x088e2d64 0x088e2d64 0x016768 0x016768 RW 0x1000
DYNAMIC 0x7972c4 0x087e02c4 0x087e02c4 0x000108 0x000108 RW 0x4
NOTE 0x000168 0x08048168 0x08048168 0x000020 0x000020 R 0x4
GNU_EH_FRAME 0x7008ec 0x087488ec 0x087488ec 0x0108fc 0x0108fc R 0x4
GNU_STACK 0x000000 0x00000000 0x00000000 0x000000 0x000000 RW 0x4
Section to Segment mapping:
Segment Sections...
00
01 .interp
02 .interp .note.ABI-tag .hash .dynsym .gnu.version
.gnu.version_r .rel.dyn .rel.plt .init .plt .text .fini .rodata
.eh_frame_hdr .eh_frame .gcc_except_table
03 .ctors .dtors .jcr .dynamic .got .got.plt .data .dynbss .bss
04 .dynstr .gnu.liblist .gnu.conflict
05 .dynamic
06 .note.ABI-tag
07 .eh_frame_hdr
08
--
Tom London
4:28 p.m.
New subject: Adding two new booleans to httpd to tighten it's security.
Tom London wrote:
LOAD 0x000000 0x08048000 0x08048000 0x7970f9 0x7970f9 RWE
0x1000
LOAD 0x7970fc 0x087e00fc 0x087e00fc 0x00bc68 0x101e44 RWE 0x1000
Wow, that's truly horribly bad. I would refrain from using that code
until it's fixed. Somebody who cares might want to contact that
company. Their build technology is very screwed. There is no reason to
have two segments. It seems they modified the linker scripts without
having the slightest bit of clue.
--
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
4:53 p.m.
New subject: Adding two new booleans to httpd to tighten it's security.
On 12/11/05, Ulrich Drepper <drepper(a)redhat.com> wrote:
Tom London wrote:
> LOAD 0x000000 0x08048000 0x08048000 0x7970f9 0x7970f9 RWE 0x1000
> LOAD 0x7970fc 0x087e00fc 0x087e00fc 0x00bc68 0x101e44 RWE 0x1000
Wow, that's truly horribly bad. I would refrain from using that code
until it's fixed. Somebody who cares might want to contact that
company. Their build technology is very screwed. There is no reason to
have two segments. It seems they modified the linker scripts without
having the slightest bit of clue.
OK, I posted this to the 'skype support' area of their website.
I'll provide whatever updates I get......
Thanks for the help.
tom
--
Tom London
5 p.m.
New subject: Adding two new booleans to httpd to tighten it's security.
On 12/11/05, Ulrich Drepper <drepper(a)redhat.com> wrote:
Tom London wrote:
> path="/usr/lib/vmware/lib/libgdk-x11-2.0.so.0/libgdk-x11-2.0.so.0"
> type=SYSCALL msg=audit(1134335151.660:39): arch=40000003 syscall=125 per=400000
This is indeed a text relocation issue. Since the code is LGPLed they
have to provide you with the sources. Just use compile and use
eu-findtextrel to determine the sources of the text relocation.
For completeness: I've posted this problem to the vmware
support/discussion group as well.
Petr (support ultra wizard) is usually pretty good at responding.
I'll post what I get......
tom
--
Tom London
6703
days inactive
6705
days old
selinux@lists.fedoraproject.org
11 comments
3 participants
participants (3)
-
Nicolas Mailhot -
Tom London -
Ulrich Drepper