IIRC there was (at one time) a check box in system-config-security to force
autorelabel at the next reboot. Since it is now not there I looked through
the rpm changelog to see why it was dropped ... I did not find an entry for
autorelabel but I did find:
- Remove support for modifying tunables since policy source will be
disappearing in the future (#160896).
I have browsed/searched the various selinux mailing lists and not found
anything which discussed this. Can someone expand one what is going on and
how policy changes will be made in the future?
Is this similar to the kernel source situation where we will need to install
the src rpm for selinux-policy to get at the sources?
I have started (really just started) to try using the MCS capabilities
available in FC5 development. As I go through this, some thought occur to
1. MCS is intended (as I understand it) to simplify some of the capabilities
of the MLS functionality which is now in (or being developed) in FC5. This
simplification is intended to make the functionality more acceptable/useable
by a wider set of users. This is goodness! This should make an actual MLS
system (which stays current) much more possible.
2. As I see it, MCS is "simply" another type of ACL but one which (to me) is
a better design (more useable) than the existing ACL capability. However,
whereas I can categorize (protect) both files and directories with ACL, I can
currently only categorize (protect) files (not directories) with MCS. I
consider this to be a problem/deficiency.
Consider that when I create new application files (e.g, with openoffice.org),
they will not have a category assigned by default. This could leave a
sensitive file available for others to access. With directory protection,
this could be mitigated.
3. Roles ... right now I don;t see much use of roles in MCS. Now this might
be an RFE which will be done later (after stuff basically works), but I see
that one way of using MCS would require a user to be able to switch to
different roles ("newrole") in order to access files and directories with
The "requirement" is to be able to switch roles and have "all" programs that
invoke from that point on run with the new role ... including programs I run
from the menu.
Right now, the easiest way I see of having different roles is to have
different userids and requiring a user to logout/login with the new userid to
switch roles. This is for gdm login (gdm could be modified to permit
specification of the role). If I use runlevel 3, then I could terminate X,
switch roles with "newrole,", and then startx to run in the new role.
OK, these are some of my initial reactions ... comments (good, bad,
I posted this message to the fedora-list mailing list, but I haven't
as of yet gotten any answer. Could someone here shed some light on the
errors I'm seeing?
Date: Wed, 26 Oct 2005 00:30:15 -0700
Subject: SELinux errors
I'm getting lots of errors like:
/etc/selinux/targeted/contexts/files/file_contexts: line 1851 has invalid context system_u:object_r:texrel_shlib_t
/etc/selinux/targeted/contexts/files/file_contexts.homedirs: line 14 has invalid context user_u:object_r:user_home_dir_t
when I run "rpm -V selinux-policy-targeted". (As far as I can tell,
every non-null, non-comment line in /etc/..../files/* generates an
In my syslog I have thousands of errors like:
Oct 26 00:21:16 bach kernel: inode_doinit_with_dentry: context_to_sid(system_u:object_r:policy_src_t:s0) returned 22 for dev=sda4 ino=1145588
Oct 26 00:21:16 bach kernel: inode_doinit_with_dentry: context_to_sid(system_u:object_r:policy_src_t:s0) returned 22 for dev=sda4 ino=266929
which I assume are related.
I've tried reinstalling the RPMs selinux-policy-targeted and
selinux-policy-targeted-sources, and then booting with selinux=0,
running "fixfiles relabel" and then rebooting normally. No change.
I've tried googling, but I didn't find anything. Any advice (other
than turning SELinux off)?
Vladimir G. Ivanovic
Palo Alto, CA 94306
+1 650 678 8014
Is there a reason not to include /var/log/audit/audit.log in the logrotate
regime? If not, what would need to go in a logrotate script to get
selinux to start a new log file?
Clemson University Math Sciences
mjs AT clemson DOT edu
Is there is a simple libselinux call I can make in httpd to determine
whether or not the SELinux policy is enabled and applied?
I'd like to add a one-line notice to the default error_log when it is,
to give an obvious tip-off to confused new users.
A new version of setools is available for download on the Tresys Technology
Included in this release is a new tool called sechecker. This tool performs
a number of checks on a SELinux policy and is designed to be modular so that
it is easily extensible in the future. We will be extending the capability
of this tool in the next release.
Sediffx has an updated user interface that separates key elements of the
policy difference for easier analysis (for example rules that were removed
because a type was removed from the policy). Also added was the ability to
specify renamed types when computing a difference.
Libapol now has support for storing some additional policy components such
as MLS, and constraints.
Various bug fixes are included in this release as well.
I'd also like to mention again that the new FC4 policy of only applying
SELinux policy if httpd is started from the init script is confusing the
hell out of people. It breaks the principle of least astonishment. I'd
much rather live with the fact that SELinux policy is *always* applied,
and the fallout from that, than see this confusion of people hitting
SELinux policy issues, get confused, restart httpd, see them disappear,
I'd really like to see this change reverted for FC5.
> Paul Howarth wrote:
>> On Wed, 2005-11-02 at 12:31 +0100, dragoran wrote:
>>> the selinux-targeted-policy in fc4 prevents samba from sharing a dvd
>>> I had to disable selinux protection for samba to get this to work.
>>> Should I fill this in bugzilla?
>> Try mounting the dvd using the mount option
> this does not work...
> it is still
> system_u:object_r:iso9660_t (which does not work)
It works for me:
# mount -r -o fscontext=system_u:object_r:samba_share_t /dev/hdc
The resulting mountpoint /media/cdrom is browsable using samba.