selinux June 2006

selinux@lists.fedoraproject.org

45 participants
61 discussions

Re: Apache/PHP module boot restriction?
by Stephen Smalley 26 Jun '06

26 Jun '06

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

3 3

Selinux Sources
by Miguel Fernandes 23 Jun '06

23 Jun '06

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!

2 1

rpmbuild and selinux
by Eric Tanguy 22 Jun '06

22 Jun '06

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

4 10

new mock package
by Eric Tanguy 22 Jun '06

22 Jun '06

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

2 1

RE: SELinux Module Packaging in FC5
by Joshua Brindle 21 Jun '06

21 Jun '06

> 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?

2 1

RE: SELinux Module Packaging in FC5
by Joshua Brindle 21 Jun '06

21 Jun '06

> 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?

2 1

selinux-policy-devel?
by Paul Howarth 21 Jun '06

21 Jun '06

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.

2 5

RE: SELinux Module Packaging in FC5
by Joshua Brindle 21 Jun '06

21 Jun '06

> 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.

2 1

RE: SELinux Module Packaging in FC5
by Joshua Brindle 21 Jun '06

21 Jun '06

> 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.

2 1

unidentified audit msg
by David-Alexandre Davidson 21 Jun '06

21 Jun '06

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.

2 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

selinux June 2006