RE: Can not access files in own home directory
by David Balazic
> From: Russell Coker[SMTP:russell@coker.com.au]
>
> On Wed, 9 Jun 2004 17:42, David Balazic <david.balazic(a)hermes.si> wrote:
> > Because I get a failure right 5 minutes after installation.
> >
> > I did a SELinux enabled install of FC2 ( Workstation type ).
> > In firstboot I created a user.
>
> This is a known bug, when firstboot creates a user it doesn't give the
> correct
> type to the home directory files. Running setfiles is the correct thing
> to
> do. But you don't have to label the entire file system, just the home
> directory for the new user.
>
setfiles requires some "policy" argument, what do I use ?
Well, I just run "fixfiles relabel" ( not is runlevel 1, as suggested by
Andrew Farris,
but level 5, is that a problem ? ).
Now login on VCx is OK, but login in X still does not work. Previously it
reported that
my home dir does not exist, but now after the "fix" , when I enter my
username and
password an blank blue screen with a mouse pointer ( pointer, not sandwatch
) appears
and nothing happens. I waited 30 seconds and switched to VC1 to check out
what is
happening, but then the screen started to blink. It went black for ~5
seconds, then back
to VC1 for a second , then black again and so on. Maybe the X server was
restarting.
Any clues ?
David Balažic
19 years, 4 months
restorecon vs. setfiles
by Gary Peck
For some reason restorecon and setfiles have different notions of what
context certain files should be. For example:
# ls -Z /usr/lib/libz.*
-rwxr-xr-x+ root root system_u:object_r:lib_t /usr/lib/libz.a
lrwxrwxrwx+ root root system_u:object_r:lib_t /usr/lib/libz.so -> libz.so.1.2.1.1
lrwxrwxrwx root root system_u:object_r:lib_t /usr/lib/libz.so.1 -> libz.so.1.2.1.1
-rwxr-xr-x root root system_u:object_r:shlib_t /usr/lib/libz.so.1.2.1.1
# restorecon -v /usr/lib/libz.*
restorecon set context /usr/lib/libz.so->system_u:object_r:shlib_t
restorecon set context /usr/lib/libz.so.1->system_u:object_r:shlib_t
# setfiles -v /etc/security/selinux/file_contexts /usr/lib/libz.*
setfiles: read 1450 specifications
setfiles: labeling files under /usr/lib/libz.a
setfiles: hash table stats: 1 elements, 1/65536 buckets used, longest chain length 1
setfiles: labeling files under /usr/lib/libz.so
setfiles: relabeling /usr/lib/libz.so from system_u:object_r:shlib_t to system_u:object_r:lib_t
setfiles: hash table stats: 1 elements, 1/65536 buckets used, longest chain length 1
setfiles: labeling files under /usr/lib/libz.so.1
setfiles: relabeling /usr/lib/libz.so.1 from system_u:object_r:shlib_t to system_u:object_r:lib_t
setfiles: hash table stats: 1 elements, 1/65536 buckets used, longest chain length 1
setfiles: labeling files under /usr/lib/libz.so.1.2.1.1
setfiles: hash table stats: 1 elements, 1/65536 buckets used, longest chain length 1
setfiles: Done.
So, restorecon thinks that *.so files should be shlib_t, whereas
setfiles thinks they should be lib_t. Which one is right and why do they
disagree? I thought that they both get their context info from the same
place.
This is with policy-1.11.3-5 and policycoreutils-1.11-4.
gary
19 years, 5 months
Mozilla accessing java engine yield denials
by Francis K Shim
Edited to show relevant details more clearly:
denied { execute }
exe=/bin/bash
name=java
scontext=user:staff_r:staff_mozilla_t tcontext=system_u:object_r:usr_t
tclass=file
denied { execute_no_trans }
exe=/bin/bash
path=/usr/java/j2re1.4.2_01/bin/java
scontext=user:staff_r:staff_mozilla_t
tcontext=system_u:object_r:usr_t
tclass=file
denied { search }
exe=/usr/java/j2re1.4.2_01/bin/java
name=vm
scontext=user:staff_r:staff_mozilla_t
tcontext=system_u:object_r:sysctl_vm_t
tclass=dir
--
Francis K Shim <francis.shim(a)sympatico.ca>
19 years, 5 months
avc denied from postgresql
by Richard Hally
During bootup the postgresql server fails to start and produced the
following avc denied message:
Jun 15 05:09:12 new2 su(pam_unix)[2414]: session opened for user
postgres by (uid=0)
Jun 15 05:09:13 new2 kernel: audit(1087290553.569:0): avc: denied {
write } for pid=2445 exe=/usr/bin/postgres name=data dev=hda2
ino=788097 scontext=user_u:user_r:user_t
tcontext=system_u:object_r:var_lib_t tclass=dir
Jun 15 05:09:14 new2 su(pam_unix)[2414]: session closed for user postgres
Jun 15 05:09:15 new2 postgresql: Starting postgresql service: failed
This is in enforcing mode with the strict policy
selinux-policy-strict-1.13.4-5
Thanks for any help,
Richard Hally
19 years, 5 months
RFE: show change of enforcing state in log ?
by Tom London
How difficult would it be to add 'old state->new state' to the log on a
change in
the enforcing state? Currently, 'setenforce' appears to be logged as a
toggle....
tom
19 years, 5 months
kernel-2.6.7-1.439: 'new' AVCs at boot time
by Tom London
kernel-2.6.7-1.439 produces the AVCs shown below. Appears to be having
some problem early on dealing with /proc (or /sys) ? (looks like
inode#1121665
is the mount point /proc or /sys on /).
This didn't happen with earlier kernels. It appears to cause no problems.
tom
--------------------------------------------------
Jun 29 07:04:05 vaio kernel: SELinux: initialized (dev sysfs, type
sysfs), uses genfs_contexts
Jun 29 07:04:05 vaio kernel: audit(1088492566.426:0): avc: denied {
search } for pid=226 exe=/bin/bash name=proc dev=hda2 ino=1121665
scontext=system_u:system_r:udev_t tcontext=system_u:object_r:file_t
tclass=dir
Jun 29 07:04:05 vaio kernel: audit(1088492566.462:0): avc: denied {
search } for pid=231 exe=/bin/bash name=proc dev=hda2 ino=1121665
scontext=system_u:system_r:udev_t tcontext=system_u:object_r:file_t
tclass=dir
Jun 29 07:04:05 vaio kernel: audit(1088492566.500:0): avc: denied {
search } for pid=236 exe=/bin/bash name=proc dev=hda2 ino=1121665
scontext=system_u:system_r:udev_t tcontext=system_u:object_r:file_t
tclass=dir
Jun 29 07:04:06 vaio kernel: audit(1088492566.538:0): avc: denied {
search } for pid=241 exe=/bin/bash name=proc dev=hda2 ino=1121665
scontext=system_u:system_r:udev_t tcontext=system_u:object_r:file_t
tclass=dir
Jun 29 07:04:06 vaio kernel: audit(1088492566.571:0): avc: denied {
search } for pid=245 exe=/bin/bash name=proc dev=hda2 ino=1121665
scontext=system_u:system_r:udev_t tcontext=system_u:object_r:file_t
tclass=dir
Jun 29 07:04:06 vaio kernel: audit(1088492566.611:0): avc: denied {
search } for pid=251 exe=/bin/bash name=proc dev=hda2 ino=1121665
scontext=system_u:system_r:udev_t tcontext=system_u:object_r:file_t
tclass=dir
Jun 29 07:04:06 vaio kernel: audit(1088492566.651:0): avc: denied {
search } for pid=257 exe=/bin/bash name=proc dev=hda2 ino=1121665
scontext=system_u:system_r:udev_t tcontext=system_u:object_r:file_t
tclass=dir
Jun 29 07:04:06 vaio kernel: audit(1088492566.721:0): avc: denied {
search } for pid=272 exe=/bin/bash name=proc dev=hda2 ino=1121665
scontext=system_u:system_r:udev_t tcontext=system_u:object_r:file_t
tclass=dir
Jun 29 07:04:06 vaio kernel: audit(1088492566.756:0): avc: denied {
search } for pid=277 exe=/bin/bash name=proc dev=hda2 ino=1121665
scontext=system_u:system_r:udev_t tcontext=system_u:object_r:file_t
tclass=dir
Jun 29 07:04:06 vaio kernel: audit(1088492566.793:0): avc: denied {
search } for pid=282 exe=/bin/bash name=proc dev=hda2 ino=1121665
scontext=system_u:system_r:udev_t tcontext=system_u:object_r:file_t
tclass=dir
Jun 29 07:04:06 vaio kernel: audit(1088492566.832:0): avc: denied {
search } for pid=287 exe=/bin/bash name=proc dev=hda2 ino=1121665
scontext=system_u:system_r:udev_t tcontext=system_u:object_r:file_t
tclass=dir
Jun 29 07:04:06 vaio kernel: audit(1088492566.855:0): avc: denied {
search } for pid=289 exe=/bin/bash name=proc dev=hda2 ino=1121665
scontext=system_u:system_r:udev_t tcontext=system_u:object_r:file_t
tclass=dir
Jun 29 07:04:06 vaio kernel: audit(1088492566.883:0): avc: denied {
search } for pid=293 exe=/bin/bash name=proc dev=hda2 ino=1121665
scontext=system_u:system_r:udev_t tcontext=system_u:object_r:file_t
tclass=dir
Jun 29 07:04:06 vaio kernel: audit(1088492566.915:0): avc: denied {
search } for pid=297 exe=/bin/bash name=proc dev=hda2 ino=1121665
scontext=system_u:system_r:udev_t tcontext=system_u:object_r:file_t
tclass=dir
Jun 29 07:04:06 vaio kernel: audit(1088492566.954:0): avc: denied {
search } for pid=303 exe=/bin/bash name=proc dev=hda2 ino=1121665
scontext=system_u:system_r:udev_t tcontext=system_u:object_r:file_t
tclass=dir
Jun 29 07:04:06 vaio kernel: audit(1088492566.994:0): avc: denied {
search } for pid=309 exe=/bin/bash name=proc dev=hda2 ino=1121665
scontext=system_u:system_r:udev_t tcontext=system_u:object_r:file_t
tclass=dir
Jun 29 07:04:06 vaio kernel: audit(1088492567.049:0): avc: denied {
search } for pid=318 exe=/bin/bash name=proc dev=hda2 ino=1121665
scontext=system_u:system_r:udev_t tcontext=system_u:object_r:file_t
tclass=dir
Jun 29 07:04:06 vaio kernel: audit(1088492567.072:0): avc: denied {
search } for pid=320 exe=/bin/bash name=proc dev=hda2 ino=1121665
scontext=system_u:system_r:udev_t tcontext=system_u:object_r:file_t
tclass=dir
Jun 29 07:04:06 vaio kernel: audit(1088492567.178:0): avc: denied {
search } for pid=334 exe=/bin/bash name=proc dev=hda2 ino=1121665
scontext=system_u:system_r:udev_t tcontext=system_u:object_r:file_t
tclass=dir
Jun 29 07:04:06 vaio kernel: audit(1088492567.181:0): avc: denied {
search } for pid=332 exe=/bin/bash name=proc dev=hda2 ino=1121665
scontext=system_u:system_r:udev_t tcontext=system_u:object_r:file_t
tclass=dir
Jun 29 07:04:06 vaio kernel: SELinux: initialized (dev ramfs, type
ramfs), uses genfs_contexts
19 years, 5 months
Re: Has the boot param syntax/semantics changed?
by Tom London
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
>
>
19 years, 5 months
additions to strict policy
by Richard Hally
Below (and as an attached file) are some policy allow rules to be added
to the strict policy.
These allow rules were developed by running the latest /devel tree using
selinux-policy-strict-sources-1.13.10-3 and putting the resulting avc
denied messages through audit2allow.
Most are necessary to perform normal operations while in enforcing mode.
Some of the rules marked "#from booting" may be candidates for dontaudit
rules.
Thanks for the help,
Richard Hally
#from " logrotate -f /etc/logrotate.conf" while root(sysadm_r)
allow logrotate_t devpts_t:dir { search };
allow logrotate_t initrc_t:process { transition };
allow logrotate_t mysqld_log_t:file { execute };
allow logrotate_t mysqld_log_t:file { execute_no_trans };
allow logrotate_t privoxy_log_t:file { execute };
allow logrotate_t privoxy_log_t:file { execute_no_trans };
allow logrotate_t selinux_config_t:dir { search };
allow logrotate_t selinux_config_t:file { getattr read };
allow logrotate_t staff_home_dir_t:dir { read search };
allow logrotate_t var_t:file { getattr };
allow logrotate_t var_t:file { read };
# from booting
allow lvm_t file_t:dir { getattr read };
allow mount_t ptmx_t:chr_file { read write };
allow mount_t rhgb_gph_t:fd { use };
allow mount_t rhgb_t:unix_stream_socket { read write };
allow rhgb_t staff_home_dir_t:dir { search };
# from booting
allow udev_t dbusd_t:unix_stream_socket { connectto };
allow udev_t dbusd_var_run_t:dir { search };
allow udev_t dbusd_var_run_t:sock_file { write };
allow udev_t file_t:dir { search };
# from exe=/usr/bin/mDNSResponder during boot
allow user_t dns_port_t:udp_socket { name_bind };
# from starting mozilla as staff_r
allow staff_mozilla_t file_t:dir { getattr };
allow staff_mozilla_t staff_home_t:file { unlink };
allow staff_mozilla_t xdm_tmp_t:dir { search };
# from normal gnome session as staff_r
allow staff_screensaver_t xdm_tmp_t:dir { search };
allow staff_screensaver_t xdm_tmp_t:sock_file { write };
allow staff_t file_t:dir { getattr };
allow staff_t staff_t:netlink_route_socket { create };
#from starting postgresql server during boot and using postgresql as user.
allow initrc_su_t postgresql_db_t:dir { search };
allow user_t postgresql_db_t:dir { add_name getattr read remove_name
search write };
allow user_t postgresql_db_t:file { create getattr read rename unlink
write };
allow staff_t user_tmp_t:sock_file { write };
allow staff_t user_t:unix_stream_socket { connectto };
#from " logrotate -f /etc/logrotate.conf" while root(sysadm_r)
allow logrotate_t devpts_t:dir { search };
allow logrotate_t initrc_t:process { transition };
allow logrotate_t mysqld_log_t:file { execute };
allow logrotate_t mysqld_log_t:file { execute_no_trans };
allow logrotate_t privoxy_log_t:file { execute };
allow logrotate_t privoxy_log_t:file { execute_no_trans };
allow logrotate_t selinux_config_t:dir { search };
allow logrotate_t selinux_config_t:file { getattr read };
allow logrotate_t staff_home_dir_t:dir { read search };
allow logrotate_t var_t:file { getattr };
allow logrotate_t var_t:file { read };
# from booting
allow lvm_t file_t:dir { getattr read };
allow mount_t ptmx_t:chr_file { read write };
allow mount_t rhgb_gph_t:fd { use };
allow mount_t rhgb_t:unix_stream_socket { read write };
allow rhgb_t staff_home_dir_t:dir { search };
# from booting
allow udev_t dbusd_t:unix_stream_socket { connectto };
allow udev_t dbusd_var_run_t:dir { search };
allow udev_t dbusd_var_run_t:sock_file { write };
allow udev_t file_t:dir { search };
# from exe=/usr/bin/mDNSResponder during boot
allow user_t dns_port_t:udp_socket { name_bind };
# from starting mozilla as staff_r
allow staff_mozilla_t file_t:dir { getattr };
allow staff_mozilla_t staff_home_t:file { unlink };
allow staff_mozilla_t xdm_tmp_t:dir { search };
# from normal gnome session as staff_r
allow staff_screensaver_t xdm_tmp_t:dir { search };
allow staff_screensaver_t xdm_tmp_t:sock_file { write };
allow staff_t file_t:dir { getattr };
allow staff_t staff_t:netlink_route_socket { create };
#from starting postgresql server during boot and using postgresql as user.
allow initrc_su_t postgresql_db_t:dir { search };
allow user_t postgresql_db_t:dir { add_name getattr read remove_name search write };
allow user_t postgresql_db_t:file { create getattr read rename unlink write };
allow staff_t user_tmp_t:sock_file { write };
allow staff_t user_t:unix_stream_socket { connectto };
19 years, 5 months
Re: Has the boot param syntax/semantics changed?
by Tom London
>
> ------------------------------------------------------------------------
>
> * /From/: Bob Gustafson <bobgus rcn com>
>
> ------------------------------------------------------------------------
> [root hoho2 user1]# cat /etc/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=enforcing
>SELINUXTYPE=strict
>POLICYTYPE=strict
>[root hoho2 user1]#
>
>Then I changed the /etc/selinux/config to the version shown below and rebooted.
>
>I got far less messages, and I was even able to go to root when clicking on
>gnome applications that required higher priority (with above config
>contents, whatever I typed was not enough, gnome kept coming back for more)
>
>[root hoho2 user1]# cat /etc/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=enforcing
>#SELINUXTYPE=strict
>SELINUXTYPE=permissive
>POLICYTYPE=strict
>[root hoho2 user1]#
>
>My assumption has been that the boot parameters override the contents of
>the /etc/selinux/config file, and that the boot param 'enforcing=0' will
>make the selinux a permissive one.
>
>Have these assumptions changed?
>
>
Well, the names have changed a bit ;) POLICYTYPE is no longer
operative, so I think
you have booted up in 'targeted' mode, not strict. 'enforcing=0' still
works for me.
Here is what you need for strict:
# 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=enforcing
# SELINUXTYPE= can take one of these two values:
# targeted - Only targeted network daemons are protected.
# strict - Full SELinux protection.
SELINUXTYPE=strict
tom
19 years, 5 months
