OpenOffice.org 1.9.100

[Aurelien Bompard]

Hi,

Just so that you know, the OpenOffice 1.9.100 rpms from www.openoffice.org
won't run on FC3 because of SELinux:
audit(1115968252.998:0): avc:  denied  { execmod } for  pid=9833
comm=soffice.bin
path=/opt/openoffice.org1.9.100/program/libicudata.so.26.0.1 dev=sda2
ino=308509 scontext=user_u:system_r:unconfined_t
tcontext=system_u:object_r:usr_t tclass=file

What should we tell the upstream rpm maintainters so that their packages
work on FC3 ? The packages used to work in an earlier version (1.9.73 I
think). It's also possible that a policy update caused it, I'm not sure, I
didn't use them very often.

Is there something we can do to fix it, or is it only in the hands of the
upstream maintainers ?

Thanks

Aurélien

On Fri, 13 May 2005 09:25:50 +0200, Aurelien Bompard said:
> Hi,
>
> Just so that you know, the OpenOffice 1.9.100 rpms from www.openoffice.org
> won't run on FC3 because of SELinux:
> audit(1115968252.998:0): avc:  denied  { execmod } for  pid=9833
> comm=soffice.bin
> path=/opt/openoffice.org1.9.100/program/libicudata.so.26.0.1 dev=sda2
> ino=308509 scontext=user_u:system_r:unconfined_t
> tcontext=system_u:object_r:usr_t tclass=file

This of course fails in the same basic manner under 'strict', except it's no
longer an unconfined_t....
> What should we tell the upstream rpm maintainters so that their packages
> work on FC3 ? The packages used to work in an earlier version (1.9.73 I
> think). It's also possible that a policy update caused it, I'm not sure, I
> didn't use them very often.
>
> Is there something we can do to fix it, or is it only in the hands of the
> upstream maintainers ?

What you can do short-term:

If you have selinux-policy-<foo>-sources installed, you can try this:

cat << EOF >> /etc/selinux/strict/src/policy/file_contexts/misc/local.fc
# Places the OpenOffice stuff puts stuff
/usr/local/OpenOffice.org1.1.4/program/.*.so(.[^/]*)*    --      system_u:object_r:shlib_t
/opt/openoffice.org[^/]*/program/.*.so(.[^/]*)*    --      system_u:object_r:shlib_t
/opt/openoffice.org[^/]*/program/soffice.bin --	system_u:object_r:bin_t
EOF

That seemed to shut the vast majority of the whinging when I tried it
with strict/permissive.  You might have to tag something with texrel_shlib_t
as well.  I don't think there's any new policy needed, just file contexts
to get the *.so's as shlib_t and the binaries as bin_t

(it's 4:37AM and one of my cats just finished dropping a litter of kittens
under my bed about a half hour, so you'll have to flush out the rest of the
answer for yourself :)

Long-term answer: when Fedora ships their official openofficeorg-*-2.0 RPMs,
we'll make sure The Right Thing happens.

[Aurelien Bompard]

OK, so there is nothing the upstream maintainers can/have to do.
How should third party vendors package their RPMs to make sure they work
with SELinux, then ? Can we exclude /opt from the audits ?

Aurélien

[Florian La Roche]

On Fri, May 13, 2005 at 12:05:02PM +0200, Aurelien Bompard wrote:
> OK, so there is nothing the upstream maintainers can/have to do.
> How should third party vendors package their RPMs to make sure they work
> with SELinux, then ? Can we exclude /opt from the audits ?

Filing bug-reports against the current policy is for sure good, if that
has real problems in it.

You can also check "pam_mount" from the newest Fedora Extras development
tree to see a package that contains a selinux policy file.

Not sure that is actually fully working, but at least that's the one
rpm I know about doing this.

greetings,

Florian La Roche

[Stephen Smalley]

On Fri, 2005-05-13 at 12:05 +0200, Aurelien Bompard wrote:
> OK, so there is nothing the upstream maintainers can/have to do.

Not entirely.  They can eliminate the need for text relocations on their
shared objects, thereby avoiding the need to mark their shared objects
with texrel_shlib_t in the policy and reducing the resulting security
risk.
> How should third party vendors package their RPMs to make sure they work
> with SELinux, then ? Can we exclude /opt from the audits ?

Ultimately, they will be able to ship a "binary policy module" for their
package that includes an explicit set of dependency requirements on what
the base policy must provide.  Binary policy module support was
developed by Tresys Technology (www.tresys.com/selinux) and is planned
to be upstreamed in June, for eventual inclusion in FC5/devel.

[Stephen Smalley]

On Fri, 2005-05-13 at 04:46 -0400, [e-mail] wrote:
> That seemed to shut the vast majority of the whinging when I tried it
> with strict/permissive.  You might have to tag something with texrel_shlib_t
> as well.  I don't think there's any new policy needed, just file contexts
> to get the *.so's as shlib_t and the binaries as bin_t

texrel_shlib_t is needed for execmod permission (text relocation).  But
it would be better to eliminate the need for the text relocation in the
first place, as it creates a security risk.

[Colin Walters]

On Fri, 2005-05-13 at 09:25 +0200, Aurelien Bompard wrote:
> Hi,
>
> Just so that you know, the OpenOffice 1.9.100 rpms from www.openoffice.org
> won't run on FC3 because of SELinux:
> audit(1115968252.998:0): avc:  denied  { execmod } for  pid=9833
> comm=soffice.bin
> path=/opt/openoffice.org1.9.100/program/libicudata.so.26.0.1 dev=sda2
> ino=308509 scontext=user_u:system_r:unconfined_t
> tcontext=system_u:object_r:usr_t tclass=file

Did you update your kernel without updating the selinux-policy-targeted
package?

[Aurelien Bompard]

Colin Walters wrote:
> Did you update your kernel without updating the selinux-policy-targeted
> package?

I don't think so:
# rpm -q selinux-policy-targeted; uname -r
selinux-policy-targeted-1.17.30-3.2
2.6.11-1.20_FC3

Aurélien