Re: [refpolicy] [PATCH] revise roles/dbadm.te (Re: dbadm.pp is not available in selinux-policy package)
by KaiGai Kohei
(2010/04/14 0:57), Christopher J. PeBenito wrote:
> On Tue, 2010-04-13 at 11:15 -0400, Daniel J Walsh wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> On 04/13/2010 09:17 AM, Christopher J. PeBenito wrote:
>>> On Tue, 2010-04-13 at 09:28 +0900, KaiGai Kohei wrote:
>>>> (2010/04/12 23:09), Christopher J. PeBenito wrote:
>>>>> On Fri, 2010-04-09 at 14:29 +0900, KaiGai Kohei wrote:
>>>>>> (2010/04/08 21:15), Daniel J Walsh wrote:
>>>>>>> As Dominick stated. I prefer to think in terms of two different roles.
>>>>>>> Login Roles, and Roles to execute in when you have privileges (IE Root).
>>>>>>>
>>>>>>> Login Roles/Types
>>>>>>> staff_t, user_t, unconfined_t, xguest_t, guest_t
>>>>>>>
>>>>>>> Three interfaces can be used to create confined login users.
>>>>>>>
>>>>>>> userdom_restricted_user_template(guest)
>>>>>>> userdom_restricted_xwindows_user_template(xguest)
>>>>>>> userdom_unpriv_user_template(staff)
>>>>>>>
>>>>>>>
>>>>>>> Admin Roles/Types
>>>>>>> logadm_t, webadm_t, secadm_t, auditadm_t
>>>>>>>
>>>>>>> The following interface can be used to create an Admin ROle
>>>>>>> userdom_base_user_template(logadm)
>>>>>>>
>>>>>>>
>>>>>>> sysadm_t is sort of a hybrid, most people use it as an Admin Role.
>>>>>>>
>>>>>>>
>>>>>>> I imagine that you login as a confined user and then use sudo/newrole to
>>>>>>> switch roles to one of the admin roles.
>>>>>>
>>>>>> The attached patch revises roles/dbadm.te (to be applied on the upstream
>>>>>> reference policy). It uses userdom_base_user_template() instead of the
>>>>>> userdom_unpriv_user_template(), and should be launched via sudo/newrole.
>>>>>> In the default, it intends the dbadm_r role to be launched by staff_r role.
>>>>>
>>>>> Why does dbadm need to run setfiles?
>>>>
>>>> The database files (typically, /var/lib/(se)?pgsql/*) have to be labeled
>>>> correctly, so I thought dbadm needs to run setfiles.
>>>> However, as long as they initialize database files using init script,
>>>> initrc_t domain performs this initial labeling, so it might not be necessary.
>>>>
>>>> On the other hand, PostgreSQL support a feature to use multiple disks
>>>> within a single database instance for performance utilization.
>>>> (Called TABLESPACE; I don't know whether MySQL has such a feature.)
>>>>
>>>> http://archives.postgresql.org/pgsql-general/2006-08/msg00142.php
>>>>
>>>> It requires administrators to assign proper security context on the secondary
>>>> directory, or to mount the secondary disk with context='...' option.
>>>>
>>>> Is there any good idea?
>>>>
>>>> Or, it should not be a task for dbadm?
>>>
>>> Ok, the transition for setfiles is fine.
>>>
>>
>> I would be carefull with this. Since setfiles can take a parameter of a
>> file context file. I think it would be better to only give
>> relabefrom/relabelto privs for all labels dbadm_t can manage. Then
>> figure out what access is required to mount.
>
> Good point. We should probably reconsider the setfiles usage from
> webadm too.
The attached patch is a revised one.
- seutil_domtrans_setfiles() was removed
- staff_role_change_to() was removed, and I put dbadm_role_change()
on the staff.te
- Fix an obvious typo.
It is not clear for me whether the idea to allow relabelfrom/relabelto
for all the files dbadm_t can manage, because it is eventually necessary
someone to relabel (or assign initial labels) files from unlabeled one
to managed labels when we mount a new disk.
If so, should it be a task of sysadm_t to mount new disk and assign
security context correctly, instead of webadm_t/dbadm_t?
Thanks,
--
KaiGai Kohei <kaigai(a)ak.jp.nec.com>
13 years, 9 months
Apache/PHP mail function SELinux permissions
by Ted Rule
I've had a "problem" recently with SELinux permissions related to PHP's
mail functions. These appear to give rise to two different classes of error,
one for read permissions on the httpd_t domain itself, and one for
read/write permission on a file in the httpd_tmp_t domain.
aureport gives this:
$ sudo aureport -a |grep system_mail |head
6. 25/10/09 13:12:48 sendmail user_u:system_r:system_mail_t:s0 11 file
read user_u:system_r:httpd_t:s0 denied 116101
7. 25/10/09 13:15:57 sendmail user_u:system_r:system_mail_t:s0 11 file
read write user_u:object_r:httpd_tmp_t:s0 denied 116102
17. 25/10/09 13:39:46 sendmail user_u:system_r:system_mail_t:s0 11 file
read write user_u:object_r:httpd_tmp_t:s0 denied 116124
23. 25/10/09 13:43:04 sendmail user_u:system_r:system_mail_t:s0 11 file
read write user_u:object_r:httpd_tmp_t:s0 denied 116136
24. 25/10/09 13:43:04 sendmail user_u:system_r:system_mail_t:s0 11 file
read user_u:system_r:httpd_t:s0 denied 116136
30. 25/10/09 13:52:57 sendmail user_u:system_r:system_mail_t:s0 11 file
read write user_u:object_r:httpd_tmp_t:s0 denied 116148
31. 25/10/09 13:52:57 sendmail user_u:system_r:system_mail_t:s0 11 file
read user_u:system_r:httpd_t:s0 denied 116148
39. 25/10/09 14:01:18 sendmail user_u:system_r:system_mail_t:s0 11 file
read write user_u:object_r:httpd_tmp_t:s0 denied 116168
40. 25/10/09 14:01:18 sendmail user_u:system_r:system_mail_t:s0 11 file
read user_u:system_r:httpd_t:s0 denied 116168
48. 25/10/09 14:11:50 sendmail user_u:system_r:system_mail_t:s0 11 file
read write user_u:object_r:httpd_tmp_t:s0 denied 116181
Policy on the Apache hosts currently uses selinux-policy-2.4.6-203.el5
Looking in more detail at ausearch we see that the httpd_t related avc
is apparently related to an "eventpoll" file descriptor, whilst the
httpd_tmp_t
avc is probably for a file created by php in /tmp.
Looking at the php source code itself, I see that it is simply opening a
temporary file containing the body of the Email and pouring it via a
pipe into an instance of sendmail via popen().
As such, it seems likely that both classes of avc's are simply file
descriptors "leaking" into the popen'ed child process running in the
system_mail_t domain.
Sadly, for other reasons, the Apache hosts are still in permissive, so
it's currently unclear to me whether the PHP mail function would fail
completely if either
of these permissions are denied in enforcing mode, but it makes me
wonder whether there would be any sense in a wider solution to leaky
descriptors which caused popen() itself to close all file descriptors
other than STDIN/STDOUT/STDERR if the popen'ed executable implies a
domain transition. Alternatively, one might envisage a set of selinux
booleans which allowed a more granular control of leaked descriptors
outside of STDIN/STDOUT/STDERR.
The other potential policy improvement would be for system_mail_t to
simply "dontaudit" denials relating to eventpoll class file descriptors
and temporary files in context *_tmp_t.
time->Sun Oct 25 13:12:48 2009
type=SYSCALL msg=audit(1256476368.217:116101): arch=40000003 syscall=11
success=yes exit=0 a0=97e5ff0 a1=97e5798 a2=97e5600 a3=40 items=0
ppid=20809 pid=22040 auid=500 uid=48 gid=48 euid=
48 suid=48 fsuid=48 egid=51 sgid=51 fsgid=51 tty=(none) ses=11966
comm="sendmail" exe="/usr/sbin/sendmail.sendmail"
subj=user_u:system_r:system_mail_t:s0 key=(null)
type=AVC msg=audit(1256476368.217:116101): avc: denied { read } for
pid=22040 comm="sendmail" path="eventpoll:[129640960]" dev=eventpollfs
ino=129640960 scontext=user_u:system_r:system
_mail_t:s0 tcontext=user_u:system_r:httpd_t:s0 tclass=file
----
time->Sun Oct 25 13:15:57 2009
type=SYSCALL msg=audit(1256476557.234:116102): arch=40000003 syscall=11
success=yes exit=0 a0=9ab7ff0 a1=9ab7798 a2=9ab7600 a3=40 items=0
ppid=21767 pid=22099 auid=500 uid=48 gid=48 euid=
48 suid=48 fsuid=48 egid=51 sgid=51 fsgid=51 tty=(none) ses=11966
comm="sendmail" exe="/usr/sbin/sendmail.sendmail"
subj=user_u:system_r:system_mail_t:s0 key=(null)
type=AVC msg=audit(1256476557.234:116102): avc: denied { read write }
for pid=22099 comm="sendmail"
path=2F746D702F2E7863616368652E302E302E313032353230323336322E6C6F636B202864656C65746
56429 dev=dm-3 ino=97922 scontext=user_u:system_r:system_mail_t:s0
tcontext=user_u:object_r:httpd_tmp_t:s0 tclass=file
----
time->Sun Oct 25 13:39:46 2009
type=SYSCALL msg=audit(1256477986.012:116124): arch=40000003 syscall=11
success=yes exit=0 a0=97f1ff0 a1=97f1798 a2=97f1600 a3=40 items=0
ppid=23457 pid=23560 auid=500 uid=48 gid=48 euid=
48 suid=48 fsuid=48 egid=51 sgid=51 fsgid=51 tty=(none) ses=11966
comm="sendmail" exe="/usr/sbin/sendmail.sendmail"
subj=user_u:system_r:system_mail_t:s0 key=(null)
type=AVC msg=audit(1256477986.012:116124): avc: denied { read write }
for pid=23560 comm="sendmail"
path=2F746D702F2E7863616368652E302E302E313032353230323336322E6C6F636B202864656C65746
56429 dev=dm-3 ino=97922 scontext=user_u:system_r:system_mail_t:s0
tcontext=user_u:object_r:httpd_tmp_t:s0 tclass=file
----
time->Sun Oct 25 13:43:04 2009
type=SYSCALL msg=audit(1256478184.954:116136): arch=40000003 syscall=11
success=yes exit=0 a0=8f48ff0 a1=8f48798 a2=8f48600 a3=40 items=0
ppid=23048 pid=23802 auid=500 uid=48 gid=48 euid=
48 suid=48 fsuid=48 egid=51 sgid=51 fsgid=51 tty=(none) ses=11966
comm="sendmail" exe="/usr/sbin/sendmail.sendmail"
subj=user_u:system_r:system_mail_t:s0 key=(null)
type=AVC msg=audit(1256478184.954:116136): avc: denied { read } for
pid=23802 comm="sendmail" path="eventpoll:[129701955]" dev=eventpollfs
ino=129701955 scontext=user_u:system_r:system
_mail_t:s0 tcontext=user_u:system_r:httpd_t:s0 tclass=file
type=AVC msg=audit(1256478184.954:116136): avc: denied { read write }
for pid=23802 comm="sendmail"
path=2F746D702F2E7863616368652E302E302E313032353230323336322E6C6F636B202864656C65746
56429 dev=dm-3 ino=97922 scontext=user_u:system_r:system_mail_t:s0
tcontext=user_u:object_r:httpd_tmp_t:s0 tclass=file
----
time->Sun Oct 25 13:52:57 2009
type=SYSCALL msg=audit(1256478777.377:116148): arch=40000003 syscall=11
success=yes exit=0 a0=945bff0 a1=945b798 a2=945b600 a3=40 items=0
ppid=24396 pid=24439 auid=500 uid=48 gid=48 euid=
48 suid=48 fsuid=48 egid=51 sgid=51 fsgid=51 tty=(none) ses=11966
comm="sendmail" exe="/usr/sbin/sendmail.sendmail"
subj=user_u:system_r:system_mail_t:s0 key=(null)
type=AVC msg=audit(1256478777.377:116148): avc: denied { read } for
pid=24439 comm="sendmail" path="eventpoll:[129734033]" dev=eventpollfs
ino=129734033 scontext=user_u:system_r:system
_mail_t:s0 tcontext=user_u:system_r:httpd_t:s0 tclass=file
type=AVC msg=audit(1256478777.377:116148): avc: denied { read write }
for pid=24439 comm="sendmail"
path=2F746D702F2E7863616368652E302E302E313032353230323336322E6C6F636B202864656C65746
56429 dev=dm-3 ino=97922 scontext=user_u:system_r:system_mail_t:s0
tcontext=user_u:object_r:httpd_tmp_t:s0 tclass=file
----
--
Ted Rule
Director, Layer3 Systems Ltd
Layer3 Systems Limited is registered in England. Company no 3130393
W: http://www.layer3.co.uk/
13 years, 10 months
[ANN] Linux Security Summit 2010 - Announcement and CFP
by James Morris
==========================================================================
ANNOUNCEMENT AND CALL FOR PARTICIPATION
LINUX SECURITY SUMMIT 2010
==========================================================================
DESCRIPTION
The Linux Security Summit is a technical forum for collaboration
between Linux developers, researchers, and end users. Its primary aim
is to foster community efforts in analyzing and solving Linux security
challenges.
The format of the summit will be:
* Selected brief presentations
* Lightning talks
* Q&A panel sessions
DATES / LOCATION
The Linux Security Summit for 2010 will be held on the 9th of August in
Boston, USA. It will be co-located with LinuxCon [1], at the
Renaissance Boston Waterfront.
Note that Linux Security Summit attendees must be registered to attend
LinuxCon. See the LinuxCon site for details on registration, travel,
and accommodation.
http://events.linuxfoundation.org/events/linuxcon
The CFP is currently open, and will close on 4th of June (see below).
Accepted speakers will be notified by 9th of June.
WHO SHOULD ATTEND
The event is open to all registered LinuxCon attendees.
You do not have to be a "security person" to attend -- we're seeking a
diverse range of attendees, and welcome the participation of general
developers, researchers, operations, and end-users.
There will be several panel sessions in addition to brief, selected
presentations, with a strong focus on discussion.
CALL FOR PARTICIPATION
The program committee currently seeks proposals for:
Presentations:
Brief technical talks in 30 minute slots, including at least 10
minutes of discussion (i.e. the maximum length of the presentation
alone is 20 minutes). Papers are encouraged, and slides should be
minimal.
Presentation abstracts should be approximately 150 words in length.
Panel discussion topics:
If you'd like to see an issue discussed in a Q&A style panel, send it
in. Note that this may result in you volunteering to participate in
a panel.
Topic areas include, but are not limited to:
* System hardening
* Access control
* Cryptography
* Integrity control
* Hardware security
* Networking
* Storage
* Virtualization
* Desktop
* Tools
* Management
* Case studies
* Emerging technologies, threats & techniques
Proposals must be submitted before the end of June 4th, 2010.
(That's not far away!)
Accepted speakers will be notified by June 9th, 2010.
We will probably receive more proposals than can be accommodated. If
your talk is not accepted, you may wish to give a lightning talk or
raise a topic in a discussion panel.
Lightning talks and discussion panel agendas will be coordinated closer
to the event on the event mailing list, and on-site.
Proposals should be submitted in plain text via email to the program
committee at: lss-pc (_at_) ext.namei.org
MAILING LIST
Everyone planning to attend should join the event mailing list:
https://ext.namei.org/mailman/listinfo/linux-security-summit
Coordination of panel discussions and lightning talks will occur on the
list. Updates and announcements about the event will also be sent to
the list.
WEB SITE
Please also note the Linux Security Summit web site:
https://security.wiki.kernel.org/index.php/LinuxSecuritySummit2010
which will be kept updated with all available information on the event.
PROGRAM COMMITTEE
The Linux Security Summit for 2010 is organized by:
* James Morris, Red Hat
* Serge Hallyn, IBM
* Paul Moore, HP
* Stephen Smalley, NSA
* Joshua Brindle, Tresys
* Tetsuo Handa, NTT Data
* Herbert Xu, Red Hat
* John Johansen, Canonical
* Andrew G. Morgan, Google
* Kees Cook, Canonical
* Casey Schaufler, Smack Project
The program committee may be contacted as a group via email:
lss-pc (_at_) ext.namei.org
REFERENCES
[1] LinuxCon: http://events.linuxfoundation.org/events/linuxcon
13 years, 11 months
selinux and kickstart
by irfan irfan
Somebody can help me, how to install xguest with kickstart file. in the log file semanage can`t run in kickstart process. Is selinux disable on kickstart process ?
Thanks before
13 years, 12 months
Re: sandbox complaint
by mark
Daniel wrote:
> On 05/27/2010 12:19 PM, m.roth(a)5-cent.us wrote:
>> Daniel wrote:
>>> On 05/27/2010 12:00 PM, m.roth(a)5-cent.us wrote:
>>>> Daniel wrote:
>>>>> On 05/27/2010 11:49 AM, m.roth(a)5-cent.us wrote:
>>>>>> Updating a system from CentOS 5.4 (current) to 5.5, and I see:
>>>>>>
>>>>>> libsepol.scope_copy_callback: zosremote: Duplicate declaration in
>>>>>> module:
>>>>>> type/attribute zos_remote_t
>>>>>> libsemanage.semanage_link_sandbox: Link packages failed
>>>>>> semodule: Failed!
>> <snip>
>>>>> Do you have multiple pp files definitin zosremote?
>> <snip>
>>> locate -r zos.*remote
>>>
>>> Might find the bad pp file.
<snip>
>> I don't believe they want me to remove it. Doing the locate, I find:
>>> locate -r zos.*remote | grep .pp
>> /etc/selinux/mls/modules/active/modules/zosremote.pp
>> /etc/selinux/mls/modules/previous/modules/zosremote.pp
>> /etc/selinux/targeted/modules/active/modules/zos_remote.pp
>> /etc/selinux/targeted/modules/previous/modules/zos_remote.pp
>> /old/etc/selinux/targeted/modules/active/modules/zos_remote.pp
>> /old/etc/selinux/targeted/modules/previous/modules/zos_remote.pp
>> /old/usr/share/selinux/mls/audispd-zos-remote.pp
>> /old/usr/share/selinux/strict/audispd-zos-remote.pp
>> /old/usr/share/selinux/targeted/audispd-zos-remote.pp
>> /usr/share/selinux/mls/zosremote.pp
>> /usr/share/selinux/targeted/zosremote.pp
>>
>> So, which should I get rid of, that was not cleaned up during the
>> update?
>
> Remove all audispd-zos-remote.pp and zos_remote.pp
>
> We ship zosremote.pp
Ok... I can do that, but are you saying to just rm it, and not whatever
package it came in?
And if it's not correct, why is it here, anyway? Anyone on the CentOS
list? I don't want to screw around with this as "oh, it's only his weird
problem", I figure that it's happening to a lot of other folks, and I'd
like to make the problem go away for everyone. That, of course, means it
the incorrect stuff needs to be removed from whatever package it's in....
mark
14 years
sandbox complaint
by mark
Updating a system from CentOS 5.4 (current) to 5.5, and I see:
libsepol.scope_copy_callback: zosremote: Duplicate declaration in module:
type/attribute zos_remote_t
libsemanage.semanage_link_sandbox: Link packages failed
semodule: Failed!
Any ideas as to what's going on, or why?
mark "glad selinux is disabled on that box"
14 years
Fedora 13 autorelabel
by Vadym Chepkov
Hi,
It seems something got broken in initscripts on Fedora 13, if you initiate relabel via 'touch /.autorelabel'
or 'fixfiles onboot' and reboot after the relabeling process is done SELinux remains in "permissive" state, beware.
I have submitted bz#595823 about it.
Vadym
14 years
userhelper consolehelper role
by Matthew Ife
It would appear that this is a new macro in fedora 13 but I dont believe
it is complete.
Whenever you run consolehelper from a RBAC account (in my case staff_t)
it does not work. When I ran audit2allow it was apparent a whole bunch
of different access vectors are needed to properly run graphical
utilities that might take advantage of consolehelper.
Running as sysadm_t was unaffected (I assume theres no transition in
this type to a consolehelper domain). I was running the command
"system-config-users" at the time.
Here is the audit2allow output. I've not sanitized this at all to find
out what is really relevent and what isnt.
require {
type staff_t;
type sysadm_t;
type staff_consolehelper_t;
type admin_home_t;
type xdm_var_run_t;
type xauth_exec_t;
type xauth_home_t;
class process { setsched transition };
class capability { sys_nice chown dac_override };
class dir { write search remove_name add_name };
class shm { unix_read write unix_write read destroy create };
class file { execute setattr read create execute_no_trans write getattr
link unlink open };
role sysadm_r;
}
#============= staff_consolehelper_t ==============
#!!!! The source type 'staff_consolehelper_t' can write to a 'dir' of
the following type:
# pcscd_var_run_t
allow staff_consolehelper_t admin_home_t:dir { write remove_name search
add_name };
#!!!! The source type 'staff_consolehelper_t' can write to a 'file' of
the following types:
# pcscd_var_run_t, krb5_host_rcache_t
allow staff_consolehelper_t admin_home_t:file { write getattr link read
create unlink open };
allow staff_consolehelper_t self:capability { sys_nice chown
dac_override };
allow staff_consolehelper_t self:process setsched;
allow staff_consolehelper_t self:shm { unix_read write unix_write read
destroy create };
allow staff_consolehelper_t xauth_exec_t:file { read execute open
execute_no_trans };
#!!!! The source type 'staff_consolehelper_t' can write to a 'file' of
the following types:
# pcscd_var_run_t, krb5_host_rcache_t
allow staff_consolehelper_t xauth_home_t:file { write getattr setattr
read create unlink open };
#!!!! The source type 'staff_consolehelper_t' can write to a 'dir' of
the following type:
# pcscd_var_run_t
allow staff_consolehelper_t xdm_var_run_t:dir { write remove_name
add_name };
allow staff_consolehelper_t xdm_var_run_t:file { write create unlink
link };
auth_read_pam_pid(staff_consolehelper_t)
corecmd_shell_entry_type(staff_consolehelper_t)
files_list_tmp(staff_consolehelper_t)
files_read_usr_files(staff_consolehelper_t)
files_read_usr_symlinks(staff_consolehelper_t)
files_rw_etc_files(staff_consolehelper_t)
files_search_home(staff_consolehelper_t)
fs_getattr_xattr_fs(staff_consolehelper_t)
fs_rw_tmpfs_files(staff_consolehelper_t)
gnome_read_gconf_home_files(staff_consolehelper_t)
kernel_read_system_state(staff_consolehelper_t)
miscfiles_read_fonts(staff_consolehelper_t)
rpm_delete_db(staff_consolehelper_t)
rpm_read_db(staff_consolehelper_t)
userdom_list_user_home_dirs(staff_consolehelper_t)
userdom_read_user_home_content_files(staff_consolehelper_t)
14 years
Re: Device nodes have no type when booting a 2.6.32.*.fc12 kernel [SOLVED]
by Karl-Michael Schneider
On Tue, May 25, 2010 at 11:47 AM, Karl-Michael Schneider
<karlmicha(a)gmail.com> wrote:
> On Mon, May 24, 2010 at 12:28 PM, Stephen Smalley <sds(a)tycho.nsa.gov> wrote:
>> On Mon, 2010-05-24 at 15:07 -0400, Stephen Smalley wrote:
>>> On Mon, 2010-05-24 at 11:54 -0700, Karl-Michael Schneider wrote:
>>> > I have fc12 installed on a Lenovo R61 laptop with two kernels:
>>> >
>>> > kernel-2.6.31.12-174.2.22.fc12.i686
>>> > kernel-2.6.32.12-115.fc12.i686
>>> >
>>> > The 2.6.31 kernel has no problem. But when I try to boot the 2.6.32
>>> > kernel it fails because SELinux is blocking access to device nodes. I
>>> > can only boot the 2.6.32 kernel in single user mode. The reason is
>>> > that /dev and all files in it have no type:
>>> >
>>> > $ ls -lZ /dev
>>> > crw-------. root root system_u:object_r:unlabeled_t:s0 agpgart
>>> <snip>
>>> > The filesystem is ext3 on LVM:
>>> >
>>> > $ cat /etc/fstab
>>> > /dev/VolGroup00/LogVol00 / ext3 defaults 1 1
>>> > ...
>>> >
>>> > The filesystem was created when I installed FC9. Later I upgraded to
>>> > FC12. But the problem only appeared when the kernel was updated from
>>> > 2.6.31 to 2.6.32. All 2.6.32 kernels so far had the same problem.
>>> >
>>> > I have already relabeled the filesystem, but it didn't help. I tried
>>> > restorecon -R -v /dev after booting the 2.6.32 kernel but it didn't do
>>> > anything.
>>>
>>> Sounds like the devtmpfs mount with a policy that doesn't know about it.
>>> dmesg | grep SELinux
>>> grep /dev /proc/mounts
>>
>> I suspect your policy update didn't go cleanly and aborted during %post,
>> especially if you tried going all the way from F9 to F12. I'd suggest
>> doing:
>> mv /etc/selinux/targeted /etc/selinux/targeted.orig
>> yum reinstall selinux-policy-targeted
>
> Thanks. This resolved the /dev labeling problem.
>
> Now I got security exceptions for a number of applications. I remember
> I got the same exceptions after I upgraded to FC12. So I booted with
> enforcing=0 and built a local policy module from audit.log as
> described in the audit2allow man page. I post it here:
>
> module local 1.0;
>
> require {
> type unconfined_t;
> type system_dbusd_var_run_t;
> type sound_device_t;
> type usr_t;
> type xdm_var_lib_t;
> type dri_device_t;
> type NetworkManager_t;
> type user_home_t;
> type var_spool_t;
> type initrc_t;
> type system_dbusd_t;
> type var_lock_t;
> type xdm_dbusd_t;
> type session_dbusd_tmp_t;
> type unlabeled_t;
> type removable_device_t;
> type consolekit_t;
> type var_lib_t;
> type gnomeclock_t;
> type gconfd_exec_t;
> type var_t;
> type xdm_t;
> class process sigchld;
> class unix_stream_socket connectto;
> class dbus send_msg;
> class chr_file { getattr setattr };
> class file { rename execute setattr read execmod getattr
> execute_no_trans write ioctl unlink open create append };
> class sock_file { write create unlink };
> class blk_file { getattr setattr };
> class dir { write search setattr read remove_name add_name };
> }
>
> #============= NetworkManager_t ==============
> allow NetworkManager_t unlabeled_t:file { ioctl execute read open
> getattr execute_no_trans };
> allow NetworkManager_t var_lib_t:file { read create open getattr };
> allow NetworkManager_t var_lock_t:dir search;
>
> #============= consolekit_t ==============
> allow consolekit_t dri_device_t:chr_file { getattr setattr };
> allow consolekit_t removable_device_t:blk_file { getattr setattr };
> allow consolekit_t sound_device_t:chr_file { getattr setattr };
>
> #============= gnomeclock_t ==============
> allow gnomeclock_t initrc_t:dbus send_msg;
>
> #============= unconfined_t ==============
> #!!!! This avc can be allowed using the boolean 'allow_execmod'
>
> allow unconfined_t usr_t:file execmod;
>
> #============= unlabeled_t ==============
> allow unlabeled_t unconfined_t:process sigchld;
>
> #============= xdm_dbusd_t ==============
> allow xdm_dbusd_t gconfd_exec_t:file { read execute open execute_no_trans };
> allow xdm_dbusd_t self:unix_stream_socket connectto;
> allow xdm_dbusd_t session_dbusd_tmp_t:sock_file { write create unlink };
> allow xdm_dbusd_t system_dbusd_t:dbus send_msg;
> allow xdm_dbusd_t system_dbusd_t:unix_stream_socket connectto;
> allow xdm_dbusd_t system_dbusd_var_run_t:dir search;
> allow xdm_dbusd_t system_dbusd_var_run_t:sock_file write;
> allow xdm_dbusd_t xdm_t:unix_stream_socket connectto;
> #!!!! The source type 'xdm_dbusd_t' can write to a 'dir' of the following types:
> # session_dbusd_tmp_t, tmp_t
>
> allow xdm_dbusd_t xdm_var_lib_t:dir { read write add_name remove_name };
> #!!!! The source type 'xdm_dbusd_t' can write to a 'file' of the following type:
> # session_dbusd_tmp_t
>
> allow xdm_dbusd_t xdm_var_lib_t:file { rename read create write
> getattr unlink open append };
>
> #============= xdm_t ==============
> allow xdm_t initrc_t:dbus send_msg;
> #!!!! This avc can be allowed using the boolean 'allow_polyinstantiation'
>
> allow xdm_t session_dbusd_tmp_t:dir setattr;
> #!!!! The source type 'xdm_t' can write to a 'dir' of the following types:
> # xserver_log_t, var_log_t, xdm_log_t, pam_var_run_t, xdm_var_lib_t,
> xdm_var_run_t, xdm_home_t, pam_var_console_t, pcscd_var_run_t,
> xkb_var_lib_t, xdm_rw_etc_t, var_lock_t, root_t, tmp_t, var_t,
> user_fonts_t, user_tmpfs_t, xdm_spool_t, fonts_cache_t,
> user_home_dir_t, locale_t, var_auth_t, tmpfs_t, var_spool_t,
> user_tmp_t, auth_cache_t, var_lib_t, var_run_t, xdm_tmpfs_t,
> xdm_tmp_t, root_t, nfs_t
>
> allow xdm_t session_dbusd_tmp_t:dir { write remove_name add_name };
> allow xdm_t session_dbusd_tmp_t:sock_file { write create unlink };
> #!!!! This avc can be allowed using the boolean 'allow_polyinstantiation'
>
> allow xdm_t user_home_t:file { write rename };
> allow xdm_t var_spool_t:file unlink;
> allow xdm_t var_t:dir setattr;
> allow xdm_t var_t:file { write rename create unlink setattr };
>
Adding the local policy module did not fix all the problems. I had to
relabel the filesystem, and that fixed it (no need for a local policy
module anymore).
14 years
