more latest selinux policy change problems

[Peter Magnusson]

A little script that runs in cron complained about stuff after I turned on
selinux for apache again;

mv: cannot set setfscreatecon `user_u:object_r:httpd_sys_script_rw_t':
Permission denied

so I changed the selinux perms on these files. Hope it will work next time 
I turn on selinux for apache. Because now its off again because of this:

Tested what gallery (http://gallery.sourceforge.net/) would think about 
selinux. It didnt like it at all. It said that it has no rights to write in 
the userfile.

And how would I know what I should set the perms to get it working?

Jun 21 06:27:25 sysbabe kernel: audit(1119328045.441:0): avc:  denied  { 
write } for  pid=29609 exe=/usr/sbin/httpd name=userdb.dat dev=hda2 
ino=688180 scontext=root:system_r:httpd_t 
tcontext=system_u:object_r:httpd_sys_content_t tclass=file
Jun 21 06:27:25 sysbabe kernel: audit(1119328045.442:0): avc:  denied  { 
write } for  pid=29609 exe=/usr/sbin/httpd name=userdb.dat dev=hda2 
ino=688180 scontext=root:system_r:httpd_t 
tcontext=system_u:object_r:httpd_sys_content_t tclass=file

is what is says. Same problem on an other vhost with an counter, just other 
name= of course.

This is thing above is just the mainpage. It must be able to write dirs 
also, when creating new albums. It must also be able to execute
/usr/bin/convert and maybe other programs also. Hmm, and it stores tmp 
files in /tmp also. httpd_sys_content_execute_tmpfiles_t on /tmp maybe? :) 
I have no idea how many fixes that are needed to get everything working.
Is it any *generic* for apache-can-write-whatever-it wants in selinux?
As long that apache cant write in *system files* or execute anything as
root Im quite happy.

Did the fedora team expect problems like this to be created with the latest 
selinux policy change or is it a suprise for you? Its fine to have it by 
default in new release of fedora but not CHANGE it in a update.

[Tom Lisjac]

On 6/20/05, Peter Magnusson  wrote:
> Its fine to have it by
> default in new release of fedora but not CHANGE it in a update.

I agree. The 1.17.30-3.9 update was a scary experience. Fortunately
none of my production servers broke, but some of the Slackware boxes
I'm currently converting to Fedora have deeply embedded /www
directories. If they'd been in service and I had applied 1.17.30-3.9,
I guess they would have gone down.

Suggestion: Functional changes that can break existing installs
shouldn't be provided as normal updates... they should be included in
the next OS version. Otherwise, if the update policy is perceived to
put running servers at risk, it won't be long before the community
stops taking Fedora seriously.

Best regards,

-Tom

[Chuck Anderson]

On Tue, Jun 21, 2005 at 12:33:48AM -0600, Tom Lisjac wrote:
> Suggestion: Functional changes that can break existing installs
> shouldn't be provided as normal updates... they should be included in
> the next OS version. Otherwise, if the update policy is perceived to
> put running servers at risk, it won't be long before the community
> stops taking Fedora seriously.

That isn't the goal of Fedora, though.  Updates are specifically NOT
backported to older trees.  Instead, you get the update for the latest
OS release, rebuilt for the older releases.  If you want a more stable 
tree with backported fixes, then use RHEL.

[Tom Lisjac]

On 6/21/05, Chuck Anderson  wrote:
> On Tue, Jun 21, 2005 at 12:33:48AM -0600, Tom Lisjac wrote:
> > Suggestion: Functional changes that can break existing installs
> > shouldn't be provided as normal updates... they should be included in
> > the next OS version. Otherwise, if the update policy is perceived to
> > put running servers at risk, it won't be long before the community
> > stops taking Fedora seriously.
>
> That isn't the goal of Fedora, though.  Updates are specifically NOT
> backported to older trees.  Instead, you get the update for the latest
> OS release, rebuilt for the older releases.

Thanks for the clarification. Could you refer me to the place where
this policy is stated? The only reference I can find that might allude
to it is item 3 on this page:

http://fedora.redhat.com/about/objectives.html

Woudn't it be better to simply stop pushing SELinux updates to older
versions rather then continuing to apply new and possibliy
incompatible features of the newer release?
> If you want a more stable
> tree with backported fixes, then use RHEL.

We can't afford RHEL. If updating installed Fedoras is going to cause
them to become unstable after a new version release, we'll have no
choice but to migrate to another OS.

Best regards,

-Tom

[Stephen Smalley]

On Wed, 2005-06-22 at 13:29 -0600, Tom Lisjac wrote:
> Woudn't it be better to simply stop pushing SELinux updates to older
> versions rather then continuing to apply new and possibliy
> incompatible features of the newer release?

I don't think that the breakage was intentional/expected.  As I
understand it, Dan only pushes updated policies to older releases as
needed to fix specific bugs or to deal with newer kernels (which may
introduce newer SELinux permission checks, and thus require new policy
allowing those permissions).  I'd view the breakage as a bug.

[Daniel Normolle]

Tom Lisjac wrote:
> We can't afford RHEL. If updating installed Fedoras is going to cause
> them to become unstable after a new version release, we'll have no
> choice but to migrate to another OS.

I backed out of the problematic policy update by getting the
source for the previous update, using rpmbuild to construct the
binary .rpm and using the --force option to return to the
earlier policy.  If I can do it, you can do it.  It was
inconvenient, but nothing compared to my peer Windoze
users' weekly struggles with the latest and greatest anti-virus
software.

dpn

[Daniel J Walsh]

Tom Lisjac wrote:
> On 6/21/05, Chuck Anderson  wrote:
> > On Tue, Jun 21, 2005 at 12:33:48AM -0600, Tom Lisjac wrote:
> > > Suggestion: Functional changes that can break existing installs
> > > shouldn't be provided as normal updates... they should be included in
> > > the next OS version. Otherwise, if the update policy is perceived to
> > > put running servers at risk, it won't be long before the community
> > > stops taking Fedora seriously.
> >
> > That isn't the goal of Fedora, though.  Updates are specifically NOT
> > backported to older trees.  Instead, you get the update for the latest
> > OS release, rebuilt for the older releases.
>
> Thanks for the clarification. Could you refer me to the place where
> this policy is stated? The only reference I can find that might allude
> to it is item 3 on this page:
>
> http://fedora.redhat.com/about/objectives.html
>
> Woudn't it be better to simply stop pushing SELinux updates to older
> versions rather then continuing to apply new and possibliy
> incompatible features of the newer release?
> > If you want a more stable
> > tree with backported fixes, then use RHEL.
>
> We can't afford RHEL. If updating installed Fedoras is going to cause
> them to become unstable after a new version release, we'll have no
> choice but to migrate to another OS.
>
> Best regards,
>
> -Tom

The goal is not to make it unstable, and we still have not figured out 
what went wrong.  But Fedora updates to the latest kernel, for security
updates, rather than backporting like we do for RHEL.  So when a Kernel 
gets updated, we needed to update policy, and that is where the
fun began.  Currently FC4 is going through major bug fixes in Policy, so 
I don't envision many more changes to FC3.
> --
> fedora-selinux-list mailing list
> [e-mail]
> http://www.redhat.com/mailman/listinfo/fedora-selinux-list

[Stephen Smalley]

On Tue, 2005-06-21 at 07:11 +0200, Peter Magnusson wrote:
> And how would I know what I should set the perms to get it working?
>
> Jun 21 06:27:25 sysbabe kernel: audit(1119328045.441:0): avc:  denied  { 
> write } for  pid=29609 exe=/usr/sbin/httpd name=userdb.dat dev=hda2 
> ino=688180 scontext=root:system_r:httpd_t 
> tcontext=system_u:object_r:httpd_sys_content_t tclass=file
> Jun 21 06:27:25 sysbabe kernel: audit(1119328045.442:0): avc:  denied  { 
> write } for  pid=29609 exe=/usr/sbin/httpd name=userdb.dat dev=hda2 
> ino=688180 scontext=root:system_r:httpd_t 
> tcontext=system_u:object_r:httpd_sys_content_t tclass=file
>
> is what is says. Same problem on an other vhost with an counter, just other 
> name= of course.

Per earlier postings on this list, have you tried:
setsebool -P httpd_builtin_scripting=1 httpd_unified=1
> Did the fedora team expect problems like this to be created with the latest 
> selinux policy change or is it a suprise for you? Its fine to have it by 
> default in new release of fedora but not CHANGE it in a update.

I think it was a bug in the spec file's handling of the booleans file.

[Peter Magnusson]

On Wed, 22 Jun 2005, Stephen Smalley wrote:
> Per earlier postings on this list, have you tried:
> setsebool -P httpd_builtin_scripting=1 httpd_unified=1

Nope, but the latest selinux-policy-targeted (1.17.30-3.15) fixed all 
problems.

I got alot of other problems, rndc reload didnt work for bind for example.
But now everything works.
> > Did the fedora team expect problems like this to be created with the latest
> > selinux policy change or is it a suprise for you? Its fine to have it by
> > default in new release of fedora but not CHANGE it in a update.
>
> I think it was a bug in the spec file's handling of the booleans file.

Ok.