10:58 p.m.
Yeah, you don't want to set SELINUXTYPE to permissive. That appears to
be the
same as selecting the 'targeted' policy. (I guess, 'not strict').
(The comment in the config file says SELINUXTYPE can take one of two
values, targeted or strict).
To select permissive mode, you set SELINUX=permissive. For me, setting
SELINUX to permissive is the same as booting with 'enforcing=0'.
tom
------------------------------------------------------------------------
* /From/: Bob Gustafson <bobgus rcn com>
If POLICYTYPE is no longer used, then the file that contains that
deprecated param should be either overwritten during the 'yum update'
process, or a note or message should show up somewhere (visibly) during the
'yum update' process.
If the user's config file is not changed, but the program changes in the
'yum update', then there is a problem (perhaps even a 'process bug').
Is there a 'permissive' value for SELINUXTYPE?
Using the boot param 'enforcing=0' seems to be different than setting the
SELINUXTYPE=permissive for me.
enforcing=0 was less permissive...
BobG
8:01 a.m.
New subject: Has the boot param syntax/semantics changed?
On Mon, 2004-06-28 at 23:58, Tom London wrote:
Yeah, you don't want to set SELINUXTYPE to permissive. That
appears to
be the
same as selecting the 'targeted' policy. (I guess, 'not strict').
(The comment in the config file says SELINUXTYPE can take one of two
values, targeted or strict).
If you set SELINUXTYPE= to a name that does not exist under
/etc/selinux, then /sbin/init will fail to load a policy, so it should
die if enforcing or proceed under permissive/no-policy otherwise.
--
Stephen Smalley <sds(a)epoch.ncsc.mil>
National Security Agency
8:15 a.m.
New subject: Has the boot param syntax/semantics changed?
Yeah, got it.
I have my params set to:
[root@hoho2 etc]# cat selinux/config
# This file controls the state of SELinux on the system.
# SELINUX= can take one of these three values:
# enforcinfg - SELinux security policy is enforced.
# permissive - SELinux prints warnings instead of enforcing.
# disabled - No SELinux policy is loaded.
#SELINUX=disabled
SELINUX=permissive
SELINUXTYPE=strict
Also just for good measure - my boot params are 'selinux=1 enforcing=0'
Would be nice if the routines parsing these values would holler out if
there are syntax errors (or manual mis-readings.., incorrect values, etc.)
BobG
On Mon, 28 Jun 2004 20:58:10 -0700, Tom London wrote:
Yeah, you don't want to set SELINUXTYPE to permissive. That
appears to
be the
same as selecting the 'targeted' policy. (I guess, 'not strict').
(The comment in the config file says SELINUXTYPE can take one of two
values, targeted or strict).
To select permissive mode, you set SELINUX=permissive. For me, setting
SELINUX to permissive is the same as booting with 'enforcing=0'.
tom
8:38 a.m.
New subject: Has the boot param syntax/semantics changed?
On Tue, 2004-06-29 at 09:15, Bob Gustafson wrote:
Would be nice if the routines parsing these values would holler out
if
there are syntax errors (or manual mis-readings.., incorrect values, etc.)
Run selinuxconfig to see your current configuration settings.
/sbin/init should log a warning if it cannot open the policy file, e.g.
due to bad configuration setting for the SELINUXTYPE, but there might be
an issue with the present call to log().
--
Stephen Smalley <sds(a)epoch.ncsc.mil>
National Security Agency
9:03 a.m.
New subject: Has the boot param syntax/semantics changed?
On Tue, 29 Jun 2004 09:38:32 -0400, Stephen Smalley wrote:
On Tue, 2004-06-29 at 09:15, Bob Gustafson wrote:
> Would be nice if the routines parsing these values would holler out if
> there are syntax errors (or manual mis-readings.., incorrect values, etc.)
Run selinuxconfig to see your current configuration settings.
[root@hoho2 etc]# selinuxconfig
selinux state="permissive"
policypath="/etc/selinux/strict"
default_type_path="/etc/selinux/strict/contexts/default_type"
default_context_path="/etc/selinux/strict/contexts/default_contexts"
default_failsafe_context_path="/etc/selinux/strict/contexts/failsafe_context"
binary_policy_path="/etc/selinux/strict/policy/policy"
user_contexts_path="/etc/selinux/strict/contexts/users/"
contexts_path="/etc/selinux/strict/contexts"
[root@hoho2 etc]#
Hmm, that looks pretty useful.
I wonder what it would have looked like with the wrong values in the
/etc/selinux/config?
And to what effect?
/sbin/init should log a warning if it cannot open the policy file, e.g.
due to bad configuration setting for the SELINUXTYPE, but there might be
an issue with the present call to log().
I did not see any failures, but clearly I had the wrong values in my
/etc/selinux/config file:
[root@hoho2 log]# grep policy messages*
messages:Jun 27 06:48:25 hoho2 kernel: audit(1088336905.471:0): avc:
granted {
load_policy } for pid=4626 exe=/usr/sbin/load_policy
scontext=root:sysadm_r:lo
ad_policy_t tcontext=system_u:object_r:security_t tclass=security
messages:Jun 27 06:48:50 hoho2 kernel: audit(1088336930.238:0): avc:
granted {
load_policy } for pid=4688 exe=/usr/sbin/load_policy
scontext=root:sysadm_r:lo
ad_policy_t tcontext=system_u:object_r:security_t tclass=security
...
...
BobG
9:08 a.m.
New subject: Has the boot param syntax/semantics changed?
On Tue, 2004-06-29 at 10:03, Bob Gustafson wrote:
Hmm, that looks pretty useful.
I wonder what it would have looked like with the wrong values in the
/etc/selinux/config?
For the SELINUXTYPE=, there is no fixed set of legitimate values,
because anyone might install their own "foo" policy under /etc/selinux.
So with SELINUXTYPE=permissive, you would have just seen output like:
policypath="/etc/selinux/permissive"
default_type_path="/etc/selinux/permissive/contexts/default_type"
...
And to what effect?
Since the "permissive" directory didn't exist, init wouldn't be able to
load a policy. If enforcing, then init should have died immediately
with an error. If permissive, it should have logged a warning and
proceeded in permissive with no policy loaded.
I did not see any failures, but clearly I had the wrong values in my
/etc/selinux/config file:
It likely wouldn't be captured in /var/log/messages, since this is
happening _before_ syslogd is started. But there should be a message on
the console (but I agree that I also do not see one, so this is a bug).
--
Stephen Smalley <sds(a)epoch.ncsc.mil>
National Security Agency
7252
days inactive
7252
days old
selinux@lists.fedoraproject.org
5 comments
3 participants
participants (3)
-
Bob Gustafson -
Stephen Smalley -
Tom London