FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor


 
 
LinkBack Thread Tools
 
Old 02-12-2008, 01:38 PM
Daniel J Walsh
 
Default SELinux

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Terry - Fedora Core wrote:
> Richard England wrote:
>> Terry - Fedora Core wrote:
>>> As I reported on another thread, SELinux has caused me trouble and
>>> blocked access to my hard disks.
>>>
>>> To solve the problem, I set SELinux to "permissive" mode. Am I
>>> positive that SELinux caused the problem of not being able access the
>>> hard disks. No. But then when I set SELinux to permissive mode the
>>> problem disappeared. Not proof, but very strong evidence.
>>>
>>> My question:
>>>
>>> Should I enable SELinux again?
>>>
>>> What do I gain if I do?
>>>
>>> Will the gain be greater than the loss of accessing my computer hard
>>> disks?
>>>
>>> And if I do, how do I try to prevent it from locking me out of the
>>> hard disks again?
>>>
>>> How do I determine what caused SELinux to block access, how much
>>> trouble is it to change SELinux to prevent it from doing that again?
>>>
>>> Your insights are appreciated.
>>>
>>> Terry
>>>
>> You need to provide more solid details around "...blocked access to my
>> hard disks." What error messages are you seeing? Some one on this
>> list might
> The error messages were along the lines that an application could not
> write to it's resource file in it's hidden directory in my home directory.
>
> Also, Konqueror simply refused to open any directories whatsoever. It
> displayed the directory structure in the navigation panel, but it would
> not allow access to any directory, even directories under my home
> directory. Nor would it allow access to other hard disks on the system -
> hard disks other than the hard disk that FEdora Core 8 is installed on.
> The computer was still working, but ALL directories and ALL files were
> simply not accesable, either by Konqueror or any other application. Even
> when I used File Manager (Konqueror) in super user mode or the super
> user terminal. I simply got error messages that I did not have
> sufficient permission to access the directory/file - even the super user
> (root) got the same message. I attributed t6his to SELinux based on the
> simple logic that SELinux was giving me the error messages relating to
> blocking access to something or other. See SELinux error reports below.
>> be able to assist you. Is SELinux involved? Probably, given your
>> experience but how is yet to be determine. It might be as simple as
>> a need to relabel your file system ("touch /.autorelabel" and reboot.
>> ), but provide more detail and someone can help tell you if that is
>> your problem
>>
>> I've been running F7 and F8 with SElinux enabled for as long as they
>> have both been out and have had not difficulties. So it is possible.
> I copied the SELinux Troubleshooter reports on another thread, but they
> don't seem to have made it to the list so I'll copy them below. They
> make no sense to me. It references something about labeling problems,
> but I did not label anything. I would expect the installation program to
> apply appropriate labels to everything that the user would need to do to
> download and install and configure the system for normal use so that
> SELinux would not need to complain about such things. (Note the octal
> IDs below have been randomly changed by me - I get nervous when I see
> such information being made public :-) )
>
> Terry
>
> SELinux Trouble Reports follow - 4 (converted to text from pdf by
> pdftotext)
>
>
> Summary SELinux is preventing gdm (xdm_t) "execute" to <Unknown>
> (rpm_exec_t). Detailed Description SELinux denied access requested by
> gdm. It is not expected that this access is required by gdm and this
> access may signal an intrusion attempt. It is also possible that the
> specific version or configuration of the application is causing it to
> require additional access. Allowing Access Sometimes labeling problems
> can cause SELinux denials. You could try to restore the default system
> file context for <Unknown>, restorecon -v <Unknown> If this does not
> work, there is currently no automatic way to allow this access. Instead,
> you can generate a local policy module to allow this access - see
> http://fedora.redhat.com/docs/selinux-faq-fc5/#id2961385 Or you can
> disable SELinux protection altogether. Disabling SELinux protection is
> not recommended. Please file a
> http://bugzilla.redhat.com/bugzilla/enter_bug.cgi against this package.
> Additional Information Source Context Target Context Target Objects
> Affected RPM Packages Policy RPM Selinux Enabled Policy Type MLS Enabled
> Enforcing Mode Plugin Name Host Name Platform Alert Count First Seen
> Last Seen Local ID Line Numbers Raw Audit Messages avc: denied { execute
> } for comm=gdm dev=sda7 name=rpm pid=3107
> scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tclass=file
> tcontext=system_ubject_r:rpm_exec_t:s0
> system_u:system_r:xdm_t:s0-s0:c0.c1023 system_ubject_r:rpm_exec_t:s0
> None [ file ] selinux-policy-3.0.8-44.fc8 True targeted True Enforcing
> plugins.catchall_file Home-Net Linux Home-Net 2.6.23.1-42.fc8 #1 SMP Tue
> Oct 30 13:55:12 EDT 2007 i686 i686 7 Wed 06 Feb 2008 01:50:35 PM EST Thu
> 07 Feb 2008 10:26:00 AM EST 41e3c4c1-b5da-4c6a-8917-01b4013c448f
>
> Summary SELinux is preventing gdm (xdm_t) "getattr" to /bin/rpm
> (rpm_exec_t). Detailed Description SELinux denied access requested by
> gdm. It is not expected that this access is required by gdm and this
> access may signal an intrusion attempt. It is also possible that the
> specific version or configuration of the application is causing it to
> require additional access. Allowing Access Sometimes labeling problems
> can cause SELinux denials. You could try to restore the default system
> file context for /bin/rpm, restorecon -v /bin/rpm If this does not work,
> there is currently no automatic way to allow this access. Instead, you
> can generate a local policy module to allow this access - see
> http://fedora.redhat.com/docs/selinux-faq-fc5/#id2961385 Or you can
> disable SELinux protection altogether. Disabling SELinux protection is
> not recommended. Please file a
> http://bugzilla.redhat.com/bugzilla/enter_bug.cgi against this package.
> Additional Information Source Context Target Context Target Objects
> Affected RPM Packages Policy RPM Selinux Enabled Policy Type MLS Enabled
> Enforcing Mode Plugin Name Host Name Platform Alert Count First Seen
> Last Seen Local ID Line Numbers Raw Audit Messages avc: denied { getattr
> } for comm=gdm dev=sda7 egid=0 euid=0 exe=/bin/bash exit=-13 fsgid=0
> fsuid=0 gid=0 items=0 path=/bin/rpm pid=3107
> scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 sgid=0
> subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 suid=0 tclass=file
> tcontext=system_ubject_r:rpm_exec_t:s0 tty=(none) uid=0
> system_u:system_r:xdm_t:s0-s0:c0.c1023 system_ubject_r:rpm_exec_t:s0
> /bin/rpm [ file ] rpm-4.4.2.2-3.fc8 [target] selinux-policy-3.0.8-44.fc8
> True targeted True Enforcing plugins.catchall_file Home-Net Linux
> Home-Net 2.6.23.1-42.fc8 #1 SMP Tue Oct 30 13:55:12 EDT 2007 i686 i686
> 13 Wed 06 Feb 2008 01:50:35 PM EST Thu 07 Feb 2008 10:26:00 AM EST
> 845ddb2e-69a4-6f67-5508-83456c0bff19
>
> Summary SELinux is preventing sh (loadkeys_t) "search" to <Unknown>
> (home_root_t). Detailed Description SELinux denied access requested by
> sh. It is not expected that this access is required by sh and this
> access may signal an intrusion attempt. It is also possible that the
> specific version or configuration of the application is causing it to
> require additional access. Allowing Access Sometimes labeling problems
> can cause SELinux denials. You could try to restore the default system
> file context for <Unknown>, restorecon -v <Unknown> If this does not
> work, there is currently no automatic way to allow this access. Instead,
> you can generate a local policy module to allow this access - see
> http://fedora.redhat.com/docs/selinux-faq-fc5/#id2961385 Or you can
> disable SELinux protection altogether. Disabling SELinux protection is
> not recommended. Please file a
> http://bugzilla.redhat.com/bugzilla/enter_bug.cgi against this package.
> Additional Information Source Context Target Context Target Objects
> Affected RPM Packages Policy RPM Selinux Enabled Policy Type MLS Enabled
> Enforcing Mode Plugin Name Host Name Platform Alert Count First Seen
> Last Seen Local ID Line Numbers Raw Audit Messages avc: denied { search
> } for comm=sh dev=sda7 egid=0 euid=0 exe=/bin/bash exit=-13 fsgid=0
> fsuid=0 gid=0 items=0 name=home pid=4986
> scontext=system_u:system_r:loadkeys_t:s0 sgid=0
> subj=system_u:system_r:loadkeys_t:s0 suid=0 tclass=dir
> tcontext=system_ubject_r:home_root_t:s0 tty=(none) uid=0
> system_u:system_r:loadkeys_t:s0 system_ubject_r:home_root_t:s0 None [
> dir ] selinux-policy-3.0.8-44.fc8 True targeted True Enforcing
> plugins.catchall_file Home-Net Linux Home-Net 2.6.23.1-42.fc8 #1 SMP Tue
> Oct 30 13:55:12 EDT 2007 i686 i686 2 Wed 06 Feb 2008 04:52:48 PM EST Wed
> 06 Feb 2008 04:52:48 PM EST 54a23c38-b925-4467-aa0e-5d3fdcc5d799
>
> Summary SELinux is preventing sh (loadkeys_t) "search" to <Unknown>
> (unconfined_home_dir_t). Detailed Description SELinux denied access
> requested by sh. It is not expected that this access is required by sh
> and this access may signal an intrusion attempt. It is also possible
> that the specific version or configuration of the application is causing
> it to require additional access. Allowing Access Sometimes labeling
> problems can cause SELinux denials. You could try to restore the default
> system file context for <Unknown>, restorecon -v <Unknown> If this does
> not work, there is currently no automatic way to allow this access.
> Instead, you can generate a local policy module to allow this access -
> see http://fedora.redhat.com/docs/selinux-faq-fc5/#id2961385 Or you can
> disable SELinux protection altogether. Disabling SELinux protection is
> not recommended. Please file a
> http://bugzilla.redhat.com/bugzilla/enter_bug.cgi against this package.
> Additional Information Source Context Target Context Target Objects
> Affected RPM Packages Policy RPM Selinux Enabled Policy Type MLS Enabled
> Enforcing Mode Plugin Name Host Name Platform Alert Count First Seen
> Last Seen Local ID Line Numbers Raw Audit Messages avc: denied { search
> } for comm=sh dev=sda7 name=terry pid=4986
> scontext=system_u:system_r:loadkeys_t:s0 tclass=dir
> tcontext=unconfined_ubject_r:unconfined_home_dir _t:s0
> system_u:system_r:loadkeys_t:s0
> unconfined_ubject_r:unconfined_home_dir_t:s0 None [ dir ]
> selinux-policy-3.0.8-44.fc8 True targeted True Enforcing
> plugins.catchall_file Home-Net Linux Home-Net 2.6.23.1-42.fc8 #1 SMP Tue
> Oct 30 13:55:12 EDT 2007 i686 i686 22 Wed 06 Feb 2008 04:52:48 PM EST
> Wed 06 Feb 2008 04:52:48 PM EST 04bec695-038f-408d-bf7a-fa3c5f6e2812
>
>>
>> ~~R
>>
>
This looks like you are logging into the system as xdm_t? If you have a
terminal shell up, execute id -Z to show what context you are logged in as.

I think your system is badly mislabeled. You can execute
touch /.autorelabel; reboot

To fix the system labeling, you should also update to the latest selinux
policy. The installation should have set the labeling in the first
place. I have no idea how you got to this state.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAkexr1YACgkQrlYvE4MpobPlWQCZASRumpCarx QKq40pD0k6OGDS
pqMAn3pDKMcefX0dZSWj+06V1W7fUmoF
=il+v
-----END PGP SIGNATURE-----

--
fedora-list mailing list
fedora-list@redhat.com
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
 
Old 08-10-2008, 11:27 PM
Ned Slider
 
Default SELinux

Hi list,

I've knocked up a contribution on SELinux here:

http://wiki.centos.org/HowTos/SELinux

I've tried to pitch it as an introduction for those not already familiar
with SELinux but also hopefully a useful reference.


I'm relatively new to SELinux and have covered pretty much everything I
know to the limits of my limited knowledge. If folks think other
material needs to be covered then it may be more appropriate for them to
make the additions rather than me. Consider it a "get the ball rolling"
contribution that the community can add to as necessary


Comments welcomed,

Ned
_______________________________________________
CentOS-docs mailing list
CentOS-docs@centos.org
http://lists.centos.org/mailman/listinfo/centos-docs
 
Old 08-11-2008, 08:14 AM
Manuel Wolfshant
 
Default SELinux

Ned Slider wrote:
Hi
list,




I've knocked up a contribution on SELinux here:




http://wiki.centos.org/HowTos/SELinux




I've tried to pitch it as an introduction for those not already
familiar with SELinux but also hopefully a useful reference.




I'm relatively new to SELinux and have covered pretty much everything I
know to the limits of my limited knowledge. If folks think other
material needs to be covered then it may be more appropriate for them
to make the additions rather than me. Consider it a "get the ball
rolling" contribution that the community can add to as necessary




Comments welcomed,



I would add the following just before "Sumamry" (in case one wants to
edit the rules suggested by audit2allow):



Building module policy manually




- grep sendmail /var/log/audit/audit.log | audit2allow -M postfix

- while reviewing the generated postfix.te

module local 1.0;



require {

******* type httpd_log_t;

******* type postfix_postdrop_t;

******* class dir getattr;

******* class file { read getattr };

}



#============= postfix_postdrop_t ==============

allow postfix_postdrop_t httpd_log_t:file getattr;




we decide that we do not want either to relabel the files or to
allow the action, but it is safe to ignore the warnings.
Therefore we edit the action rule, like below:

dontaudit postfix_postdrop_t httpd_log_t:file getattr;


We now need to compile and load the policy:

$ checkmodule -M -m -o postfix.mod postfix.te

$ semodule_package -o local.pp -m postfix.mod

$ semodule -i postfix.pp








_______________________________________________
CentOS-docs mailing list
CentOS-docs@centos.org
http://lists.centos.org/mailman/listinfo/centos-docs
 
Old 08-11-2008, 09:36 AM
"Alan Bartlett"
 
Default SELinux

On 11/08/2008, Ned Slider <ned@unixmail.co.uk> wrote:


I've knocked up a contribution on SELinux here:



http://wiki.centos.org/HowTos/SELinux



I've tried to pitch it as an introduction for those not already familiar with SELinux but also hopefully a useful reference.
Excellent work and, IMO, a very valuable reference guide.* :-D


Alan.



_______________________________________________
CentOS-docs mailing list
CentOS-docs@centos.org
http://lists.centos.org/mailman/listinfo/centos-docs
 
Old 08-11-2008, 12:22 PM
Ralph Angenendt
 
Default SELinux

Ned Slider wrote:
> Hi list,
>
> I've knocked up a contribution on SELinux here:
>
> http://wiki.centos.org/HowTos/SELinux
>
> I've tried to pitch it as an introduction for those not already familiar
> with SELinux but also hopefully a useful reference.

Great article.

What maybe should be added to the article is the fact, that SELinux
doesn't need programs to be changed, meaning that programs do not (need
to) know about SELinux at all for it to work. So a SELinux denial just
looks like a normal "access denied" to any program.

Cheers,

Ralph
_______________________________________________
CentOS-docs mailing list
CentOS-docs@centos.org
http://lists.centos.org/mailman/listinfo/centos-docs
 
Old 08-12-2008, 02:06 PM
Ned Slider
 
Default SELinux

Ralph Angenendt wrote:

Ned Slider wrote:

Hi list,

I've knocked up a contribution on SELinux here:

http://wiki.centos.org/HowTos/SELinux

I've tried to pitch it as an introduction for those not already familiar
with SELinux but also hopefully a useful reference.


Great article.


What maybe should be added to the article is the fact, that SELinux
doesn't need programs to be changed, meaning that programs do not (need
to) know about SELinux at all for it to work. So a SELinux denial just
looks like a normal "access denied" to any program.

Cheers,

Ralph



Thanks Ralph.

Added the following sentence:

Because SELinux is implemented within the kernel, individual
applications do not need to be especially written or modified to work
with SELinux. If SELinux blocks an action, this appears as just a normal
"access denied" type error to the application.

_______________________________________________
CentOS-docs mailing list
CentOS-docs@centos.org
http://lists.centos.org/mailman/listinfo/centos-docs
 
Old 08-12-2008, 02:18 PM
Ned Slider
 
Default SELinux

Manuel Wolfshant wrote:

Ned Slider wrote:

Hi list,

I've knocked up a contribution on SELinux here:

http://wiki.centos.org/HowTos/SELinux

I've tried to pitch it as an introduction for those not already
familiar with SELinux but also hopefully a useful reference.


I'm relatively new to SELinux and have covered pretty much everything
I know to the limits of my limited knowledge. If folks think other
material needs to be covered then it may be more appropriate for them
to make the additions rather than me. Consider it a "get the ball
rolling" contribution that the community can add to as necessary


Comments welcomed,
I would add the following just before "Sumamry" (in case one wants to
edit the rules suggested by audit2allow):


Building module policy manually


- grep sendmail /var/log/audit/audit.log | audit2allow -M postfix
- while reviewing the generated postfix.te

module local 1.0;

require {
type httpd_log_t;
type postfix_postdrop_t;
class dir getattr;
class file { read getattr };
}

#============= postfix_postdrop_t ==============
allow postfix_postdrop_t httpd_log_t:file getattr;


we decide that we do not want either to *relabel* the files or to
*allow* the action, but it is safe to *ignore* the warnings. Therefore
we edit the action rule, like below:


dontaudit postfix_postdrop_t httpd_log_t:file getattr;

We now need to compile and load the policy:

$ checkmodule -M -m -o postfix.mod postfix.te
$ semodule_package -o local.pp -m postfix.mod
$ semodule -i postfix.pp



Thanks Wolfy

I think I need to read up some more and expand section(s) at the end of
the document on policy modules. I'll incorporate the above into that
process.


Also, does anyone know if there are any guidelines/best practice on the
naming of custom policy modules? I'm wondering if it's wise to create
local policy modules with names like postfix or postgrey etc, as
conceivably these may later get overwritten by policy modules supplied
from elsewhere? Maybe something like postfix.local.pp might be more
appropriate?


_______________________________________________
CentOS-docs mailing list
CentOS-docs@centos.org
http://lists.centos.org/mailman/listinfo/centos-docs
 
Old 08-12-2008, 04:12 PM
Ned Slider
 
Default SELinux

Manuel Wolfshant wrote:

Ned Slider wrote:

Hi list,

I've knocked up a contribution on SELinux here:

http://wiki.centos.org/HowTos/SELinux

I've tried to pitch it as an introduction for those not already
familiar with SELinux but also hopefully a useful reference.


I'm relatively new to SELinux and have covered pretty much everything
I know to the limits of my limited knowledge. If folks think other
material needs to be covered then it may be more appropriate for them
to make the additions rather than me. Consider it a "get the ball
rolling" contribution that the community can add to as necessary


Comments welcomed,
I would add the following just before "Sumamry" (in case one wants to
edit the rules suggested by audit2allow):


Building module policy manually


- grep sendmail /var/log/audit/audit.log | audit2allow -M postfix
- while reviewing the generated postfix.te

module local 1.0;

require {
type httpd_log_t;
type postfix_postdrop_t;
class dir getattr;
class file { read getattr };
}

#============= postfix_postdrop_t ==============
allow postfix_postdrop_t httpd_log_t:file getattr;




Wolfy,

Are you able to supply an example of the audit.log AVC message(s) that
are used to create this .te policy? It might be useful to show the
actual AVC error messages in explaining this process.


Thanks,

Ned
_______________________________________________
CentOS-docs mailing list
CentOS-docs@centos.org
http://lists.centos.org/mailman/listinfo/centos-docs
 
Old 08-12-2008, 06:37 PM
Manuel Wolfshant
 
Default SELinux

On 08/12/2008 07:12 PM, Ned Slider wrote:

Manuel Wolfshant wrote:

Ned Slider wrote:

Hi list,

I've knocked up a contribution on SELinux here:

http://wiki.centos.org/HowTos/SELinux

I've tried to pitch it as an introduction for those not already
familiar with SELinux but also hopefully a useful reference.


I'm relatively new to SELinux and have covered pretty much
everything I know to the limits of my limited knowledge. If folks
think other material needs to be covered then it may be more
appropriate for them to make the additions rather than me. Consider
it a "get the ball rolling" contribution that the community can add
to as necessary


Comments welcomed,
I would add the following just before "Sumamry" (in case one wants to
edit the rules suggested by audit2allow):


Building module policy manually


- grep sendmail /var/log/audit/audit.log | audit2allow -M postfix
- while reviewing the generated postfix.te

module local 1.0;

require {
type httpd_log_t;
type postfix_postdrop_t;
class dir getattr;
class file { read getattr };
}

#============= postfix_postdrop_t ==============
allow postfix_postdrop_t httpd_log_t:file getattr;




Wolfy,

Are you able to supply an example of the audit.log AVC message(s) that
are used to create this .te policy? It might be useful to show the
actual AVC error messages in explaining this process.


Thanks,
here you are. I hope I have not trashed anything valuable but most of
the info must be here




PS, for those who might be tempted to comment about the kernel version:
I already know what you want to say.

Summary:

SELinux is preventing postdrop (postfix_postdrop_t) "getattr" to
/var/log/httpd/error_log (httpd_log_t).

Detailed Description:

SELinux denied access requested by postdrop. It is not expected that this access
is required by postdrop and this access may signal an intrusion attempt. It is
also possible that the specific version or configuration of the application is
causing it to require additional access.

Allowing Access:

Sometimes labeling problems can cause SELinux denials. You could try to restore
the default system file context for /var/log/httpd/error_log,

restorecon -v '/var/log/httpd/error_log'

If this does not work, there is currently no automatic way to allow this access.
Instead, you can generate a local policy module to allow this access - see FAQ
(http://fedora.redhat.com/docs/selinux-faq-fc5/#id2961385) Or you can disable
SELinux protection altogether. Disabling SELinux protection is not recommended.
Please file a bug report (http://bugzilla.redhat.com/bugzilla/enter_bug.cgi)
against this package.

Additional Information:

Source Context system_u:system_rostfix_postdrop_t
Target Context rootbject_r:httpd_log_t
Target Objects /var/log/httpd/error_log [ file ]
Source postdrop
Source Path /usr/sbin/postdrop
Port <Unknown>
Host sanitized
Source RPM Packages postfix-2.3.3-2
Target RPM Packages
Policy RPM selinux-policy-2.4.6-137.1.el5
Selinux Enabled True
Policy Type targeted
MLS Enabled True
Enforcing Mode Enforcing
Plugin Name catchall_file
Host Name sanitized
Platform Linux sanitized 2.6.18-53.1.21.el5 #1 SMP Tue
May 20 09:35:07 EDT 2008 x86_64 x86_64
Alert Count 599
First Seen Wed Jul 2 08:27:15 2008
Last Seen Sun Aug 10 22:47:52 2008
Local ID c303a4ea-8e7a-4acc-9118-9cc61c6a2ec8
Line Numbers

Raw Audit Messages

host=sanitized type=AVC msg=audit(1218397672.372:352): avc: denied { getattr } for pid=4262 comm="postdrop" path="/var/log/httpd/error_log" dev=md2 ino=117005 scontext=system_u:system_rostfix_postdrop_t:s0 tcontext=rootbject_r:httpd_log_t:s0 tclass=file

host=sanitized type=SYSCALL msg=audit(1218397672.372:352): arch=c000003e syscall=5 success=no exit=-13 a0=2 a1=7fffd6febca0 a2=7fffd6febca0 a3=0 items=0 ppid=4261 pid=4262 auid=4294967295 uid=48 gid=48 euid=48 suid=48 fsuid=48 egid=90 sgid=90 fsgid=90 tty=(none) comm="postdrop" exe="/usr/sbin/postdrop" subj=system_u:system_rostfix_postdrop_t:s0 key=(null)



_______________________________________________
CentOS-docs mailing list
CentOS-docs@centos.org
http://lists.centos.org/mailman/listinfo/centos-docs
 
Old 08-12-2008, 07:09 PM
Ned Slider
 
Default SELinux

Manuel Wolfshant wrote:

On 08/12/2008 07:12 PM, Ned Slider wrote:

Manuel Wolfshant wrote:

Ned Slider wrote:

Hi list,

I've knocked up a contribution on SELinux here:

http://wiki.centos.org/HowTos/SELinux

I've tried to pitch it as an introduction for those not already
familiar with SELinux but also hopefully a useful reference.


I'm relatively new to SELinux and have covered pretty much
everything I know to the limits of my limited knowledge. If folks
think other material needs to be covered then it may be more
appropriate for them to make the additions rather than me. Consider
it a "get the ball rolling" contribution that the community can add
to as necessary


Comments welcomed,
I would add the following just before "Sumamry" (in case one wants to
edit the rules suggested by audit2allow):


Building module policy manually


- grep sendmail /var/log/audit/audit.log | audit2allow -M postfix
- while reviewing the generated postfix.te

module local 1.0;

require {
type httpd_log_t;
type postfix_postdrop_t;
class dir getattr;
class file { read getattr };
}

#============= postfix_postdrop_t ==============
allow postfix_postdrop_t httpd_log_t:file getattr;




Wolfy,

Are you able to supply an example of the audit.log AVC message(s) that
are used to create this .te policy? It might be useful to show the
actual AVC error messages in explaining this process.


Thanks,
here you are. I hope I have not trashed anything valuable but most of
the info must be here




Thanks.

One wonders why postdrop is interested in /var/log/httpd/error_log?




PS, for those who might be tempted to comment about the kernel version:
I already know what you want to say.



------------------------------------------------------------------------

_______________________________________________
CentOS-docs mailing list
CentOS-docs@centos.org
http://lists.centos.org/mailman/listinfo/centos-docs


_______________________________________________
CentOS-docs mailing list
CentOS-docs@centos.org
http://lists.centos.org/mailman/listinfo/centos-docs
 

Thread Tools




All times are GMT. The time now is 01:40 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org