Re: Apache/PHP module boot restriction?
by Stephen Smalley
On Wed, 2006-02-22 at 16:41 -0800, Andrew JH Ring wrote:
> I've recently set up a Fedora Core 4 web server running Apache 2.2.0
> with PHP 5.1.2. I've managed to get Apache loading the module, after
> setting libphp5.so to shlib_t, however Apache seems to still be unable
> to access the module during boot. I'm getting a Cannot load libphp5
> cannot restore segment prot after reloc. Is this a known problem, and
> if so, how is it fixed?
cc'd fedora-selinux-list as well above, since you mentioned you were
using FC4.
This usually indicates a text relocation, which is undesirable if it can
be avoided. The stock FC4 php doesn't appear to have any text
relocations in its libphp (readelf -d libphp5.so.1 | grep TEXTREL).
Possibly it has a patch to avoid the problem.
Ideally, it would be best if you could similarly patch or fix the build
for PHP 5.1.2. If you truly need to allow it, then you can label
the .so file with the texrel_shlib_t type (since you are using FC4, I
used the old type name).
Some discussion of the SELinux memory protection tests can be found in:
http://people.redhat.com/drepper/selinux-mem.html
--
Stephen Smalley
National Security Agency
17 years, 10 months
Selinux Sources
by Miguel Fernandes
Hi, I'm using FC5 with SELinux enable, but I'm unable to find the
ploicy sources that should be located in /etc/selinux/targeted/src.
The src folder doesn't exist on /etc/selinux/targeted. In
/etc/security doesn't exist a selinux directory either. I dont know
which package I have to install to obtain this files. Thanks in
advance!
17 years, 10 months
rpmbuild and selinux
by Eric Tanguy
Since the update this morning when i try to build a package using
rpmbuild i obtain this kind of errors in the log :
Traitement des fichiers: libupnp-devel-1.4.0-1
file_contexts: invalid context system_u:object_r:usr_t
file_contexts: invalid context system_u:object_r:usr_t
file_contexts: invalid context system_u:object_r:usr_t
file_contexts: invalid context system_u:object_r:usr_t
file_contexts: invalid context system_u:object_r:usr_t
file_contexts: invalid context system_u:object_r:usr_t
file_contexts: invalid context system_u:object_r:usr_t
file_contexts: invalid context system_u:object_r:usr_t
file_contexts: invalid context system_u:object_r:usr_t
file_contexts: invalid context system_u:object_r:usr_t
someone could explain me why and how to solve this ?
Thanks
Eric
17 years, 10 months
new mock package
by Eric Tanguy
Since i updated mock to 0.6-1.fc5 when i try to run it i obtain :
init
clean
prep
This may take a while
Could not find useradd in chroot, maybe the install failed?
ending
done
What is the problem ?
Eric
17 years, 10 months
RE: SELinux Module Packaging in FC5
by Joshua Brindle
> From: Paul Howarth [mailto:paul@city-fan.org]
<snip>
> > Back to the point, my email a few times back suggested
> putting a line
> > with just ; where the rules would be in order to get a
> module without
> > rules, have you tried that?
>
> Is this with or without the requires clause?
>
> With the requires clause, the semicolon doesn't seem to make
> any difference.
Ok, now I'm not sure what is going on. I built a policy with no rules
and it linked in fine. (no ; was required either).. The policy_module
statement always brings in a ton of requires (object classes mainly) so
you'll always have requires whether you add them explicitly or not.
What problem are you running into with this?
17 years, 10 months
RE: SELinux Module Packaging in FC5
by Joshua Brindle
> From: Paul Howarth [mailto:paul@city-fan.org]
>
> Joshua Brindle wrote:
> >> From: Paul Howarth [mailto:paul@city-fan.org]
> >>
> >> Joshua Brindle wrote:
> >>>> From: Paul Howarth [mailto:paul@city-fan.org]
> >>>>
> >>>> On Tue, 2006-06-20 at 16:12 -0400, Christopher J. PeBenito wrote:
> >>>>> On Fri, 2006-05-19 at 08:03 -0400, Stephen Smalley wrote:
> >>>>>> On Thu, 2006-05-18 at 13:39 +0100, Paul Howarth wrote:
> >>>>>>> Paul Howarth wrote:
> >>>>>>>> Stephen Smalley wrote:
> >>>>>>>>> On Tue, 2006-05-16 at 17:33 +0100, Paul Howarth wrote:
> >>>>>>>>>> It contains a policy module, but the module only
> >>>> includes file contexts.
> >>>>>>>>> If this is going to be common, then semodule_package and
> >>>>>>>>> libsemanage need to allow for policy packages that
> >>>> have no policy module.
> >>>>> [cut]
> >>>>>> - Cleanly supporting policy packages that do not include
> >> a binary
> >>>>>> policy module in the tools (e.g. semodule_package) and
> >>>> libraries (e.g.
> >>>>>> libsemanage, libsepol), so that they can be used to ship
> >>>> just file
> >>>>>> contexts or other components. I don't know of any work
> >>>> in progress
> >>>>>> yet on that issue, so it may make sense to bugzilla it,
> >>>> although it
> >>>>>> is really an upstream issue, and there isn't presently an
> >>>> upstream
> >>>>>> bugzilla for selinux (just the mailing list).
> >>>>> I was looking at what it would take to support a package
> >> without a
> >>>>> module. Without the binary policy, there is one problem of
> >>>> where the
> >>>>> module name and version will come from. We could either
> >>>> add this to
> >>>>> the package itself (which would require a policy package format
> >>>>> change), or add a section to the package for module name
> >>>> and version
> >>>>> (which seems like a hack to me).
> >>>> What I'm suggesting isn't a policy package with just file
> >> contexts,
> >>>> it's one with no allow/dontaudit rules in the policy, like this:
> >>>>
> >>>> ::::::::::::::
> >>>> contagged.if
> >>>> ::::::::::::::
> >>>> # contagged.if
> >>>> #
> >>>> # This module has no interfaces
> >>>> ::::::::::::::
> >>>> contagged.fc
> >>>> ::::::::::::::
> >>>> /var/cache/contagged(/.*)?
> >>>> gen_context(system_u:object_r:httpd_cache_t,s0)
> >>>> ::::::::::::::
> >>>> contagged.te
> >>>> ::::::::::::::
> >>>> # It's currently only necessary to set file contexts for
> the cache
> >>>> directory # in this policy, but doing it in a module is
> >> easier from a
> >>>> package maintenance # point of view than using semanage
> >> and chcon in
> >>>> scriptlets
> >>>>
> >>>> policy_module(contagged, 0.3)
> >>>>
> >>>> ########################################
> >>>> #
> >>>> # Declarations
> >>>> #
> >>>>
> >>>> require {
> >>>> type httpd_cache_t;
> >>>> };
> >>>>
> >>>>
> >>>> ########################################
> >>>> #
> >>>> # Local policy
> >>>> #
> >>>>
> >>>> # (none needed)
> >>>>
> >>>>> More importantly, I believe a package without a module does
> >>>> not make
> >>>>> sense because the types and users used in the file
> >> contexts should
> >>>>> either be declared or required by the module in the package.
> >>>>> Otherwise the transaction fails late when the file contexts are
> >>>>> validated, rather than early during linking.
> >>>> I agree. It would make sense for compilation/linking of
> the module
> >>>> above to fail if the "require" wasn't present.
> >>>> Currently that doesn't happen.
> >>>>
> >>>> Paul.
> >>>>
> >>> Try putting a line with just ; where the rules would go
> and see if
> >>> that compiles.
> >> What I'm saying is that the module compiles just fine without the
> >> "require" section, and I think it might be better if it
> didn't (or at
> >> least emitted a warning) since the .fc part references
> httpd_cache_t.
> >>
> >> Paul.
> >>
> >
> > Not necessarilly. For example, a policy that declares 2
> roles and does
> > a role allow between them, while not useful, is valid. No
> requirements
> > would be necessary then.
>
> In the example I gave earlier, file context types were used
> in the .fc file; I just think it would make sense for these
> to be "required" in the same way that they would be if they
> were used in the .te file.
>
> We're getting away from the original issue here though, which
> was for clean support of policy module packages containing
> file contexts and no rules, to avoid issues like this:
>
> http://www.redhat.com/archives/fedora-selinux-list/2006-May/ms
> g00104.html
>
It would be non-trivial to change the linker to enforce requires in file
contexts but I agree that it should at least be convention.
Back to the point, my email a few times back suggested putting a line
with just ; where the rules would be in order to get a module without
rules, have you tried that?
17 years, 10 months
selinux-policy-devel?
by Paul Howarth
Perhaps the selinux-policy package should be split into an
selinux-policy and selinux-policy-devel package, with the -devel package
being needed for building new policy/modules, and the base policy
package containing just the stuff needed for regular runtime usage?
I suggest this because I just tried building a policy module in mock
with the new minimal environment and it fell over because building
policy modules requires m4, which is not in the minimal environment. So
m4 needs adding as a dep of selinux-policy (it's referenced from
/usr/share/selinux/devel/include/Makefile), and this is really a
devel-specific package that shouldn't be needed by most people, hence
splitting off a -devel subpackage and adding the dep to that makes more
sense. The -devel package could also have a dep on checkpolicy, which
would be nice...
Paul.
17 years, 10 months
RE: SELinux Module Packaging in FC5
by Joshua Brindle
> From: Paul Howarth [mailto:paul@city-fan.org]
>
> Joshua Brindle wrote:
> >> From: Paul Howarth [mailto:paul@city-fan.org]
> >>
> >> On Tue, 2006-06-20 at 16:12 -0400, Christopher J. PeBenito wrote:
> >>> On Fri, 2006-05-19 at 08:03 -0400, Stephen Smalley wrote:
> >>>> On Thu, 2006-05-18 at 13:39 +0100, Paul Howarth wrote:
> >>>>> Paul Howarth wrote:
> >>>>>> Stephen Smalley wrote:
> >>>>>>> On Tue, 2006-05-16 at 17:33 +0100, Paul Howarth wrote:
> >>>>>>>> It contains a policy module, but the module only
> >> includes file contexts.
> >>>>>>> If this is going to be common, then semodule_package and
> >>>>>>> libsemanage need to allow for policy packages that
> >> have no policy module.
> >>> [cut]
> >>>> - Cleanly supporting policy packages that do not include
> a binary
> >>>> policy module in the tools (e.g. semodule_package) and
> >> libraries (e.g.
> >>>> libsemanage, libsepol), so that they can be used to ship
> >> just file
> >>>> contexts or other components. I don't know of any work
> >> in progress
> >>>> yet on that issue, so it may make sense to bugzilla it,
> >> although it
> >>>> is really an upstream issue, and there isn't presently an
> >> upstream
> >>>> bugzilla for selinux (just the mailing list).
> >>> I was looking at what it would take to support a package
> without a
> >>> module. Without the binary policy, there is one problem of
> >> where the
> >>> module name and version will come from. We could either
> >> add this to
> >>> the package itself (which would require a policy package format
> >>> change), or add a section to the package for module name
> >> and version
> >>> (which seems like a hack to me).
> >> What I'm suggesting isn't a policy package with just file
> contexts,
> >> it's one with no allow/dontaudit rules in the policy, like this:
> >>
> >> ::::::::::::::
> >> contagged.if
> >> ::::::::::::::
> >> # contagged.if
> >> #
> >> # This module has no interfaces
> >> ::::::::::::::
> >> contagged.fc
> >> ::::::::::::::
> >> /var/cache/contagged(/.*)?
> >> gen_context(system_u:object_r:httpd_cache_t,s0)
> >> ::::::::::::::
> >> contagged.te
> >> ::::::::::::::
> >> # It's currently only necessary to set file contexts for the cache
> >> directory # in this policy, but doing it in a module is
> easier from a
> >> package maintenance # point of view than using semanage
> and chcon in
> >> scriptlets
> >>
> >> policy_module(contagged, 0.3)
> >>
> >> ########################################
> >> #
> >> # Declarations
> >> #
> >>
> >> require {
> >> type httpd_cache_t;
> >> };
> >>
> >>
> >> ########################################
> >> #
> >> # Local policy
> >> #
> >>
> >> # (none needed)
> >>
> >>> More importantly, I believe a package without a module does
> >> not make
> >>> sense because the types and users used in the file
> contexts should
> >>> either be declared or required by the module in the package.
> >>> Otherwise the transaction fails late when the file contexts are
> >>> validated, rather than early during linking.
> >> I agree. It would make sense for compilation/linking of the module
> >> above to fail if the "require" wasn't present.
> >> Currently that doesn't happen.
> >>
> >> Paul.
> >>
> >
> > Try putting a line with just ; where the rules would go and see if
> > that compiles.
>
> What I'm saying is that the module compiles just fine without
> the "require" section, and I think it might be better if it
> didn't (or at least emitted a warning) since the .fc part
> references httpd_cache_t.
>
> Paul.
>
Not necessarilly. For example, a policy that declares 2 roles and does a
role allow between them, while not useful, is valid. No requirements
would be necessary then.
17 years, 10 months
RE: SELinux Module Packaging in FC5
by Joshua Brindle
> From: Paul Howarth [mailto:paul@city-fan.org]
>
> On Tue, 2006-06-20 at 16:12 -0400, Christopher J. PeBenito wrote:
> > On Fri, 2006-05-19 at 08:03 -0400, Stephen Smalley wrote:
> > > On Thu, 2006-05-18 at 13:39 +0100, Paul Howarth wrote:
> > > > Paul Howarth wrote:
> > > > > Stephen Smalley wrote:
> > > > >> On Tue, 2006-05-16 at 17:33 +0100, Paul Howarth wrote:
> > > > >>> It contains a policy module, but the module only
> includes file contexts.
> > > > >>
> > > > >> If this is going to be common, then semodule_package and
> > > > >> libsemanage need to allow for policy packages that
> have no policy module.
> > [cut]
> > > - Cleanly supporting policy packages that do not include a binary
> > > policy module in the tools (e.g. semodule_package) and
> libraries (e.g.
> > > libsemanage, libsepol), so that they can be used to ship
> just file
> > > contexts or other components. I don't know of any work
> in progress
> > > yet on that issue, so it may make sense to bugzilla it,
> although it
> > > is really an upstream issue, and there isn't presently an
> upstream
> > > bugzilla for selinux (just the mailing list).
> >
> > I was looking at what it would take to support a package without a
> > module. Without the binary policy, there is one problem of
> where the
> > module name and version will come from. We could either
> add this to
> > the package itself (which would require a policy package format
> > change), or add a section to the package for module name
> and version
> > (which seems like a hack to me).
>
> What I'm suggesting isn't a policy package with just file
> contexts, it's one with no allow/dontaudit rules in the
> policy, like this:
>
> ::::::::::::::
> contagged.if
> ::::::::::::::
> # contagged.if
> #
> # This module has no interfaces
> ::::::::::::::
> contagged.fc
> ::::::::::::::
> /var/cache/contagged(/.*)?
> gen_context(system_u:object_r:httpd_cache_t,s0)
> ::::::::::::::
> contagged.te
> ::::::::::::::
> # It's currently only necessary to set file contexts for the
> cache directory # in this policy, but doing it in a module is
> easier from a package maintenance # point of view than using
> semanage and chcon in scriptlets
>
> policy_module(contagged, 0.3)
>
> ########################################
> #
> # Declarations
> #
>
> require {
> type httpd_cache_t;
> };
>
>
> ########################################
> #
> # Local policy
> #
>
> # (none needed)
>
> > More importantly, I believe a package without a module does
> not make
> > sense because the types and users used in the file contexts should
> > either be declared or required by the module in the package.
> > Otherwise the transaction fails late when the file contexts are
> > validated, rather than early during linking.
>
> I agree. It would make sense for compilation/linking of the
> module above to fail if the "require" wasn't present.
> Currently that doesn't happen.
>
> Paul.
>
Try putting a line with just ; where the rules would go and see if that
compiles.
17 years, 10 months
unidentified audit msg
by David-Alexandre Davidson
Hi, I recently observed a strange behavior of selinux while serving
web content over a smb share. The result was some images not showing
with httpd returning a forbidden status. After verifying all other
possible issue. I found this strange entry in my audit.log file :
type=AVC msg=audit(1150863068.013:12309): avc: denied { 0x100000 }
for pid=14365 comm="httpd" name="stock" dev=cifs ino=361051
scontext=root:system_r:httpd_t:s0 tcontext=system_u:object_r:cifs_t:s0
tclass=file
type=SYSCALL msg=audit(1150863068.013:12309): arch=40000003
syscall=196 success=no exit=-13 a0=9a76740 a1=bfece07c a2=2c8ff4
a3=2008171 items=1 pid=14365 auid=0 uid=48 gid=48 euid=48 suid=48
fsuid=48 egid=48 sgid=48 fsgid=48 comm="httpd" exe="/usr/sbin/httpd"
type=CWD msg=audit(1150863068.013:12309): cwd="/"
type=PATH msg=audit(1150863068.013:12309): item=0
name="/home/testeur/var/www/manage/public_domains_icons/CrystalClear-GNOME-1.0.0/22x22/stock/stock-help.png"
flags=0
Is there someone who knows what this 0x100000 permission is? I tried
to compile a loadable module with the corresponding allow statement
(I'm on core 5) but the 0x100000 does not appear to be a valid element
and it fails to compile. I observed this behavior on different
files(for example in this msg the denial occur on the "stock" folder
of the path, but I've seen it on the 22x22 folder as well). Restarting
the system results in some file that were forbidden to show up without
reason and some that were ok to just stop being served by httpd
(always giving the 0x100000 dennial)
At first I suspected a problem with the smb (cifs) mount but
everything work perfectly if I try to access the mount directly. Then
I suspected apache but the forbidden status code seems directly
related to the audit msg.
Anyone is welcome to help, I'm quite lost on that matter.
17 years, 10 months
