selinux blocks lircmd
by kwhiskerz
SELinux is blocking the lircmd remote-controlled mouse from starting.
I have lirc properly set up and am able to use it to control amarok, kaffeine
&c when I start irkick, so I know that the remote is not defective and that
the system is reading the signals sent.
I use the lircm mouse to control programs remotely. I have the mouse defined
in xorg.conf and it used to work perfectly in f7 (when I had, in frustration,
disabled selinux).
In f8, I insist on finally using selinux in the default enforcing mode. The
problem with lircmd has been persisting since about f3 or f4 and since then,
I have had to disable selinux to get it to work. After all of this time,
there must be a way for linux software to co-exist with selinux?
Xorg.0.log excerpt:
(**) Option "Protocol" "IMPS/2"
(**) LircMouse: Device: "/dev/lircm"
(**) LircMouse: Protocol: "IMPS/2"
(**) Option "SendCoreEvents"
(**) LircMouse: always reports core events
(**) Option "Device" "/dev/lircm"
(EE) xf86OpenSerial: Cannot open device /dev/lircm
Permission denied.
(EE) LircMouse: cannot open input device
(EE) PreInit failed for input device "LircMouse"
(II) UnloadModule: "mouse"
>From the SELinux troubleshooter:
SELinux is preventing /usr/bin/Xorg (xdm_xserver_t) "read write" to
(device_t).
Raw Audit Messages:
avc: denied { read write } for comm=X dev=tmpfs egid=0 euid=0
exe=/usr/bin/Xorg exit=-13 fsgid=0 fsuid=0 gid=0 items=0 name=lircm pid=2076
scontext=system_u:system_r:xdm_xserver_t:s0-s0:c0.c1023 sgid=0
subj=system_u:system_r:xdm_xserver_t:s0-s0:c0.c1023 suid=0 tclass=fifo_file
tcontext=system_u:object_r:device_t:s0 tty=tty7 uid=0
16 years, 5 months
adding ssh capability to xguest user role
by Peter Harmsen
Hello,
Great addition the guest and xguest user roles.
Now I have changed with the SELinux management tool under user
mappings the user role for
a specific user account from user_u to xguest_u.
Works like a charm and I'am pretty pleased.
If only i could give that user ssh access given the above scenario.
--
I have made this letter longer than usual, because i lack the time to
make it short.
16 years, 5 months
pam_ssh
by Martin Ebourne
Hi,
Since I upgraded to Fedora 8 selinux has started blocking pam_ssh (sets
up ssh-agent when you log in) from working.
I've made a policy module which I plan to propose for the rpm (see
below) but I wanted to check here first to make sure it's all sane. All
the permissions I've granted were asked for at some point on the gdm
login, it took several iterations to get it working. I've copied them
for console and ssh since I also have it configured for those.
Any feedback welcome.
Cheers,
Martin.
policy_module(pam_ssh,VERSION)
require {
type local_login_t;
type local_login_tmp_t;
type ssh_agent_exec_t;
type sshd_t;
type xdm_t;
type user_home_ssh_t;
type var_run_t;
class dir { write add_name };
class file { read getattr execute execute_no_trans };
class sock_file create;
}
allow local_login_t ssh_agent_exec_t:file { read execute
execute_no_trans };
allow local_login_t user_home_ssh_t:file { read getattr };
allow local_login_t var_run_t:dir { write add_name };
allow local_login_t var_run_t:file { create read getattr };
allow local_login_t local_login_tmp_t:sock_file create;
allow sshd_t ssh_agent_exec_t:file { read execute execute_no_trans };
allow sshd_t user_home_ssh_t:file { read getattr };
allow sshd_t var_run_t:dir { write add_name };
allow sshd_t var_run_t:file { create read getattr };
allow sshd_t local_login_tmp_t:sock_file create;
allow xdm_t ssh_agent_exec_t:file { read execute execute_no_trans };
allow xdm_t user_home_ssh_t:file { read getattr };
allow xdm_t var_run_t:dir { write add_name };
allow xdm_t var_run_t:file { create read getattr };
allow xdm_t local_login_tmp_t:sock_file create;
16 years, 5 months
Cron after upgrade (FC6 -> FC8)
by Jouni Viikari
Is it possible to run crontab job as a root any more on FC8? I get this
in /var/log/cron and job is not run:
... crond[2511]: (root) Unauthorized SELinux context (cron/root)
Thanks,
Jouni
# ls -lZ /var/spool/cron/
-rw------- root root system_u:object_r:unconfined_cron_spool_t root
# rpm -qa | grep selinux-policy-targeted
selinux-policy-targeted-3.0.8-53.fc8
I just tried my luck (just guessing):
# chcon -t sysadm_crond_t /var/spool/cron/root
chcon: failed to change context of /var/spool/cron/root to
system_u:object_r:sysadm_crond_t: Permission denied
16 years, 5 months
restorecond not expanding ~
by Forrest Taylor
I am using RHEL5.1 selinux-policy-targeted-2.4.6-104.el5. restorecond
is not properly expanding the ~ or other wildcards
in /etc/selinux/restorecond.conf. By default, restorecond.conf
includes:
~/public_html
However, if I create that directory as a normal user, it gets the
standard context (user_home_t). If I explicitly put the full path
(e.g., /home/student/public_html), it works as expected.
Does (or will) restorecond support wildcards/regex?
Thanks,
Forrest
16 years, 5 months
files contexts override via policy module
by Laurent Jacquot
Hello,
I am sure this is a FAQ or a feature, but I want to know how to work
around:
I have cxoffice installed in my F8 home dir and I want some lib labeled
as textrel_shlib_t, but I cannot override the default user_home_t home
label via a policy module.
NOTE1 it works if the directory is not under /home
NOTE2 there is nothing in the logs if it fails
NOTE3 It has been so since the introduction of modular policy in selinux
What is what I have tried so far in F8.
[root@jack sel]#cat local.fc
#cxoffice
#/home/alex/.cxoffice/dotwine/drive_c(/.*)?/.*\.exe --
system_u:object_r:textrel_shlib_t:s0
/home/alex/cxoffice/lib/wine/kernel32.dll.so --
system_u:object_r:textrel_shlib_t:s0
[root@jack sel]#semodule_package -o local.pp -m local.mod -f local.fc
[root@jack sel]#semodule -i local.pp
[root@jack sel]#ls -Z /home/alex/cxoffice/lib/wine/kernel32.dll.so
-rwxr-xr-x alex alex
system_u:object_r:user_home_t:s0 /home/alex/cxoffice/lib/wine/kernel32.dll.so
[root@jack sel]#restorecon /home/alex/cxoffice/lib/wine/kernel32.dll.so
[root@jack sel]#ls -Z /home/alex/cxoffice/lib/wine/kernel32.dll.so
-rwxr-xr-x alex alex
system_u:object_r:user_home_t:s0 /home/alex/cxoffice/lib/wine/kernel32.dll.so
(If i use the system-config-selinux UI, I can see the new entry in the
tab context among all the regexp)
Using semanage, it works:
[root@jack sel]#semodule -r local
[root@jack sel]#semanage fcontext -a -t
textrel_shlib_t /home/alex/cxoffice/lib/wine/kernel32.dll.so
[root@jack sel]#ls -Z /home/alex/cxoffice/lib/wine/kernel32.dll.so
-rwxr-xr-x alex alex
system_u:object_r:user_home_t:s0 /home/alex/cxoffice/lib/wine/kernel32.dll.so
[root@jack sel]#restorecon /home/alex/cxoffice/lib/wine/kernel32.dll.so
[root@jack sel]#ls -Z /home/alex/cxoffice/lib/wine/kernel32.dll.so
-rwxr-xr-x alex alex
system_u:object_r:textrel_shlib_t:s0 /home/alex/cxoffice/lib/wine/kernel32.dll.so
and the custom rule appears in system-config-selinux UI at the end of
the policy.
So how do I have my module install my contexts the same way as semanage?
Should I bugzilla it?
BTW, how do system-config-selinux browse the file context policy? Is it
possible to see also the rules and type definition?
TIA
jk
16 years, 5 months
Problems with sendmail after upgrade to F8
by Adam Huffman
After yum upgrading from F7 to F8, I'm seeing alerts whenever
fetchmail brings in new mail, even after a complete relabelling of the
system:
Summary
SELinux is preventing sendmail (sendmail_t) "search" to <Unknown>
(unconfined_home_dir_t).
Detailed Description
SELinux denied access requested by sendmail. It is not expected that this
access is required by sendmail 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 system_u:system_r:sendmail_t
Target Context unconfined_u:object_r:unconfined_home_dir_t
Target Objects None [ dir ]
Affected RPM Packages
Policy RPM selinux-policy-3.0.8-56.fc8
Selinux Enabled True
Policy Type targeted
MLS Enabled True
Enforcing Mode Enforcing
Plugin Name plugins.catchall_file
Host Name saintloup.smith.man.ac.uk
Platform Linux saintloup.smith.man.ac.uk 2.6.23.1-49.fc8 #1
SMP Thu Nov 8 22:14:09 EST 2007 x86_64 x86_64
Alert Count 18
First Seen Tue Nov 20 12:15:53 2007
Last Seen Tue Nov 20 12:30:59 2007
Local ID 3c789a3b-b8f8-4b21-a34a-bc198b90be73
Line Numbers
Raw Audit Messages
avc: denied { search } for comm=sendmail dev=dm-1 name=adam pid=5161
scontext=system_u:system_r:sendmail_t:s0 tclass=dir
tcontext=unconfined_u:object_r:unconfined_home_dir_t:s0
Summary
SELinux is preventing /usr/sbin/sendmail.sendmail (sendmail_t) "getattr" to
/home/adam (unconfined_home_dir_t).
Detailed Description
SELinux denied access requested by /usr/sbin/sendmail.sendmail. It is not
expected that this access is required by /usr/sbin/sendmail.sendmail 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 /home/adam, restorecon -v
/home/adam 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 system_u:system_r:sendmail_t
Target Context unconfined_u:object_r:unconfined_home_dir_t
Target Objects /home/adam [ dir ]
Affected RPM Packages sendmail-8.14.1-4.2.fc8 [application]
Policy RPM selinux-policy-3.0.8-56.fc8
Selinux Enabled True
Policy Type targeted
MLS Enabled True
Enforcing Mode Enforcing
Plugin Name plugins.catchall_file
Host Name saintloup.smith.man.ac.uk
Platform Linux saintloup.smith.man.ac.uk 2.6.23.1-49.fc8 #1
SMP Thu Nov 8 22:14:09 EST 2007 x86_64 x86_64
Alert Count 66
First Seen Tue Nov 20 12:15:53 2007
Last Seen Tue Nov 20 12:30:59 2007
Local ID a9ca1470-2510-4d05-baa4-48f8aa3b4474
Line Numbers
Raw Audit Messages
avc: denied { getattr } for comm=sendmail dev=dm-1 egid=500 euid=500
exe=/usr/sbin/sendmail.sendmail exit=-13 fsgid=500 fsuid=500 gid=500 items=0
path=/home/adam pid=5161 scontext=system_u:system_r:sendmail_t:s0 sgid=500
subj=system_u:system_r:sendmail_t:s0 suid=500 tclass=dir
tcontext=unconfined_u:object_r:unconfined_home_dir_t:s0 tty=(none) uid=0
I've not seen anything about sendmail in recent selinux-policy builds
- is something else wrong here?
16 years, 5 months
policy confusion
by kwhiskerz
I want to give selinux a try.
I have it set to enforcing. I noticed that there are 2 policy types: targetted
and seedit. It is currently set to seedit, although I changed nothing. Which
should I use?
16 years, 5 months
SELinux is preventing X (xdm_xserver_t) "search" to <Unknown> (hwdata_t).
by Antonio Olivares
After applying rawhide updates and starting up to new kernel 2.6.24-0.38.rc2.git6.fc9, setroubleshoot kicked in and gave the following alert:
Summary
SELinux is preventing X (xdm_xserver_t) "search" to <Unknown> (hwdata_t).
Detailed Description
SELinux denied access requested by X. It is not expected that this access is
required by X 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 system_u:system_r:xdm_xserver_t
Target Context system_u:object_r:hwdata_t
Target Objects None [ dir ]
Affected RPM Packages
Policy RPM selinux-policy-3.0.8-44.fc8
Selinux Enabled True
Policy Type targeted
MLS Enabled True
Enforcing Mode Enforcing
Plugin Name plugins.catchall_file
Host Name localhost
Platform Linux localhost 2.6.24-0.38.rc2.git6.fc9 #1 SMP
Fri Nov 16 17:20:39 EST 2007 i686 athlon
Alert Count 1
First Seen Mon 19 Nov 2007 07:25:42 AM CST
Last Seen Mon 19 Nov 2007 07:25:42 AM CST
Local ID a1fc1316-a17e-43d6-8163-a6899b0cc65c
Line Numbers
Raw Audit Messages
avc: denied { search } for comm=X dev=dm-0 name=hwdata pid=2802
scontext=system_u:system_r:xdm_xserver_t:s0 tclass=dir
tcontext=system_u:object_r:hwdata_t:s0
Regards,
Antonio
____________________________________________________________________________________
Never miss a thing. Make Yahoo your home page.
http://www.yahoo.com/r/hs
16 years, 5 months