Try II: selinux, xfs, and CentOS 6 and 5 issue [SOLVED]
by mark
I wrote:
> I partitioned GPT, and formatted, as xfs, a large (3TB) drive on a CentOS
> 6 system, which has selinux in permissive mode. I then moved the drive to a
> CentOS 5 system. When we run a copy (it mirror-copies from another system),
> we get a ton of errors. I discovered that the CentOS 5 system was
enforcing.
> I changed it to permissive, I labelled the directories and files w/
semanage,
> did a restorecon, and even did a fixfiles, and *then* I tried
/.autorelabel and
> rebooted, and we still get a ton of errors: Jun 1 17:01:32 <server>
kernel:
> inode_doinit_with_dentry:
> context_to_sid(unconfined_u:object_r:file_t:s0) returned 22 for dev=sdd1
ino=2151541032
Dan's recommendation to add context="system_u:object_r:usr_t:s0" to the
mount options in fastab does indeed seem to have solve the problem. Thanks
muchly, Dan.
mark
8 years, 10 months
Re: CentOS 7 selinux policy bug
by mark
On 06/01/15 16:27, m.roth(a)5-cent.us wrote:
> From: "Daniel J Walsh" <dwalsh(a)redhat.com>
> Cc: "Miroslav Grepl" <mgrepl(a)redhat.com>
> On 05/29/2015 04:34 PM, m.roth(a)5-cent.us wrote:
>> Daniel J Walsh wrote:
>>> On 05/29/2015 01:03 PM, m.roth(a)5-cent.us wrote:
>>>> Daniel J Walsh wrote:
>>>>> On 05/29/2015 09:20 AM, m.roth(a)5-cent.us wrote:
>>>>>> CentOS 7.1. Selinux policy, and targetted, updated two days ago.
>>>>>>
>>>>>> May 28 17:02:41 <servername> python: SELinux is preventing
>>>>>> /usr/bin/bash from execute access on the file
/usr/bin/bash.#012#012***** <...>
>>>>>> May 28 17:02:45 <servername> python: SELinux is preventing
>>>>>> /usr/bin/bash from execute access on the file
/usr/bin/uname.#012#012***** <...>
>>>>>> May 28 17:02:45 <servername> python: SELinux is preventing
>>>>>> /usr/bin/uname from execute_no_trans access on the file /usr/bin
>>>>>> /uname.#012#012***** <...>
>>>>>> May 28 17:02:47 <servername> python: SELinux is preventing
>>>>>> /usr/bin/bash from execute access on the file
/usr/bin/mailx.#012#012***** <...>
>> <snip>
>>>>> What is the avc that you are seeing?
>>>>>
>>>>> ausearch -m avc -ts recent
>>>> Hmmm, that ausearch gives no matches. However, in
>>>> /var/log/audit/audit.log
>>>> type=AVC msg=audit(1432846954.621:112734): avc: denied { execute } for
>>>> pid=1984 comm="rsync" name="bash" dev="sda3" ino=23075548
>>>> scontext=system_u:system_r:rsync_t:s0
>>>> tcontext=system_u:object_r:shell_exec_t:s0 tclass=file
>>>> type=AVC msg=audit(1432846954.628:112735): avc: denied { execute } for
>>>> pid=1987 comm="sh" name="uname" dev="sda3" ino=23071676
>>>> scontext=system_u:system_r:rsync_t:s0
>>>> tcontext=system_u:object_r:bin_t:s0
>>>> tclass=file
>>>> type=AVC msg=audit(1432846954.629:112737): avc: denied { execute } for
>>>> pid=1986 comm="sh" name="mailx" dev="sda3" ino=23072424
>>>> scontext=system_u:system_r:rsync_t:s0
>>>> tcontext=system_u:object_r:sendmail_exec_t:s0 tclass=file
>>>>
>>>> Now, my manager thinks that it's complaining that it's complaining
>>>> because we have an rsync daemon running, and every time there's an
>>>> upload, the daemon sends an email to a user.
>>>>
>>> Is the rsync set up as a client or server? Does it copy off or copy too?
>>>
>> Server. And stuff is copied onto it (it having a nice big RAID). They
>> *may* copy stuff off - not sure.
>>
> I just pushed this to fedora upstream policy
>
> commit 035cecfb52aff40a60b0bb7651aadc284e0dffb7
> Author: Dan Walsh <dwalsh(a)redhat.com>
> Date: Mon Jun 1 08:59:29 2015 -0400
>
> rsync server can be setup to send mail
>
> You can add the rules locally by compiling and installing this policy
> create myrsync.te to look like the following
> # =========================================
> policy_module(myrsync, 1.0)
>
> gen_require(`
> type rsync_t;
> ')
> mta_send_mail(rsync_t)
> # ==========================================
>
> Then execute
>
> # make -f /usr/share/selinux/devel/Makefile
> # semodule -i myrsync.pp
>
Ok, count me confused. I created that file, and tried the make, and it
failed, which is reasonable, since I see there's no Makefile. I have on
the system:
rpm -qa | grep selinux
selinux-policy-3.13.1-23.el7_1.7.noarch
libselinux-devel-2.2.2-6.el7.x86_64
libselinux-2.2.2-6.el7.x86_64
selinux-policy-targeted-3.13.1-23.el7_1.7.noarch
libselinux-utils-2.2.2-6.el7.x86_64
libselinux-python-2.2.2-6.el7.x86_64
I've never made a policy_module, just local policies, and (the audit log
with the AVCs has been rotated):
grep -i avc /var/log/audit/audit.log.1 | grep sendmail | audit2allow -M
mypol > a2apol
gives me:
module mypol 1.0;
require {
type sendmail_exec_t;
type rsync_t;
type init_t;
class process setrlimit;
class unix_stream_socket getattr;
class file { execute execute_no_trans };
}
#============= rsync_t ==============
allow rsync_t init_t:unix_stream_socket getattr;
allow rsync_t self:process setrlimit;
allow rsync_t sendmail_exec_t:file { execute execute_no_trans };
Should I use that, or is there another selinux package I need to install?
Also, what's better/the more correct way to do this: the module, or the
policy_module?
mark
8 years, 11 months
Try II: selinux, xfs, and CentOS 6 and 5 issue
by mark
Tried just the selinux list yesterday, no answers, so I'm trying again.
I partitioned GPT, and formatted, as xfs, a large (3TB) drive on a CentOS
6 system, which has selinux in permissive mode. I then moved the drive to
a CentOS 5 system. When we run a copy (it mirror-copies from another
system), we get a ton of errors. I discovered that the CentOS 5 system was
enforcing. I changed it to permissive, I labelled the directories and
files w/ semanage, did a restorecon, and even did a fixfiles, and *then* I
tried /.autorelabel and rebooted, and we still get a ton of errors:
Jun 1 17:01:32 <server> kernel: inode_doinit_with_dentry:
context_to_sid(unconfined_u:object_r:file_t:s0) returned 22 for dev=sdd1
ino=2151541032
I had to reboot to disabled to get it to shut up.
So: is there something that selinux does in CentOS 6 that is in the
labelling on the xfs filesystem that I can do something about on the
CentOS 5 system, or do I just have to leave selinux disabled (until, maybe
in the next year, we can rebuild to 7....)?
mark
8 years, 11 months
AVC denied when connecting to a socket
by Juan Orti Alcaine
Hello,
I'm trying to configure a FastCGI service, but I'm getting AVCs that I
don't understand why happen. It says that httpd_t is trying to connect
to init_t, but the socket has httpd_var_run_t label.
I have other FastCGI socket in the same server with httpd_var_run_t
label, and it works fine.
Is this a systemd bug?
This is my socket and service units:
# cat gitweb.socket
[Unit]
Description=GitWeb socket
[Socket]
SocketMode=0600
SocketUser=nginx
SocketGroup=nginx
ListenStream=/run/nginx/gitweb.sock
Accept=false
[Install]
WantedBy=multi-user.target
# cat gitweb.service
[Unit]
Description=GitWeb service
[Service]
Type=simple
ExecStart=/var/www/git/gitweb.cgi
User=nginx
Group=nginx
StandardInput=socket
# ps -efZ|grep nginx
system_u:system_r:httpd_t:s0 root 5270 1 0 10:01 ?
00:00:00 nginx: master process /usr/sbin/nginx
system_u:system_r:httpd_t:s0 nginx 5271 5270 0 10:01 ?
00:00:01 nginx: worker process
system_u:system_r:httpd_t:s0 nginx 5272 5270 0 10:01 ?
00:00:00 nginx: worker process
system_u:system_r:httpd_t:s0 nginx 5273 5270 0 10:01 ?
00:00:00 nginx: worker process
system_u:system_r:httpd_t:s0 nginx 5274 5270 0 10:01 ?
00:00:00 nginx: worker process
# ls -laZ /run/nginx (I get AVC denied when connecting to this socket)
total 0
drwxr-xr-x. 2 root root system_u:object_r:httpd_var_run_t:s0 60
may 29 09:59 .
drwxr-xr-x. 34 root root system_u:object_r:var_run_t:s0 1040
may 29 10:01 ..
srw-------. 1 nginx nginx system_u:object_r:httpd_var_run_t:s0 0
may 29 09:59 gitweb.sock
# ls -laZ /var/run/php-fpm (This socket works fine with the same label)
total 4
drwxr-xr-x. 2 root root system_u:object_r:httpd_var_run_t:s0 80 ene
1 1970 .
drwxr-xr-x. 34 root root system_u:object_r:var_run_t:s0 1040 may
29 10:01 ..
-rw-r--r--. 1 root root system_u:object_r:httpd_var_run_t:s0 3 ene
1 1970 php-fpm.pid
srw-rw----+ 1 root root system_u:object_r:httpd_var_run_t:s0 0 ene
1 1970 www.sock
Detailed AVC:
Additional Information:
Source Context system_u:system_r:httpd_t:s0
Target Context system_u:system_r:init_t:s0
Target Objects /run/nginx/gitweb.sock [ unix_stream_socket ]
Source nginx
Source Path nginx
Port <Unknown>
Host rpi
Source RPM Packages
Target RPM Packages
Policy RPM selinux-policy-3.13.1-126.fc22.noarch
Selinux Enabled True
Policy Type targeted
Enforcing Mode Enforcing
Host Name rpi
Platform Linux rpi 3.18.14-v7-jorti #1 SMP PREEMPT Wed May
27 22:11:40 CEST 2015 armv7l armv7l
Alert Count 1
First Seen 2015-05-29 10:01:42 CEST
Last Seen 2015-05-29 10:01:42 CEST
Local ID 785644e0-eeb9-4afc-8fd1-6f5c524d6dc5
Raw Audit Messages
type=AVC msg=audit(1432886502.500:2574): avc: denied { connectto }
for pid=5271 comm="nginx" path="/run/nginx/gitweb.sock"
scontext=system_u:system_r:httpd_t:s0
tcontext=system_u:system_r:init_t:s0 tclass=unix_stream_socket
permissive=0
--
Juan Orti
https://miceliux.com
GPG key: https://miceliux.com/pub/pubkey.asc
GPG fingerprint: 61F0 8272 6882 BCA6 3A35 88F6 B630 4B72 DEEB D08B
8 years, 11 months
CentOS 6 formatted xfs drive on a CentOS 5 system, selinux errors
by mark
I partitioned and formatted a large drive as vfs on a CentOS 6 system,
then copied the data from the smaller drive I'm replacing, then put
replaced the drive, and that's on CentOS5.
I did an semanage fcontext, setting it all to usr_t, and a restorecon -R,
on the CentOS 5, but when I run the job that backs up from another CentOS
5 system to the CentOS 5 system with the new drive, I get a ton of
kernel: inode_doinit_with_dentry:
context_to_sid(unconfined_u:object_r:file_t:s0) returned 22 for dev<...>
Having relabelled, I'm at a loss as to where to look to resolve this.
Googling's not helping, and I can't just reformat on the CentOS 5 system,
I've got terabytes of data, which would take a day and a half or so....
mark
8 years, 11 months
confining daemons
by George Karakougioumtzis
As i manage a small vps i wrote a simple daemon in python to read the
journal and email me anytime a service fails. The source code is located
at https://github.com/gkarakou/systemd-mailify.
As i currently have too many problems with selinux enforcing in my
desktop and i wouldn't make tests on the live system i kindly request
someone to review my selinux policy module. All the app is doing is
reading systemd-journal and name connects on smtp ports. It reads its
configuration from a file in etc (/etc/systemd-mailify.conf) and has a
dedicated service file. The executable is located in /usr/bin and a pid
file is written under /run.
Here are the relevant parts.
systemd-mailify.te
#############################
policy_module(systemd_mailify, 1.0)
type systemd_mailify_t;
type systemd_mailify_exec_t;
type systemd_unit_file_t;
type systemd_mailify_conf_t;
type systemd_mailify_var_run_t;
class tcp_socket name_connect;
init_daemon_domain(systemd_mailify_t, systemd_mailify_exec_t)
allow systemd_mailify_t systemd_mailify_conf_t : file rw_file_perms;
allow systemd_mailify_t systemd_mailify_conf_t : lnk_file { getattr read };
manage_files_pattern(systemd_mailify_t, systemd_mailify_var_run_t,
systemd_mailify_var_run_t)
files_config_file(systemd_mailify_conf_t);
files_pid_file(systemd_mailify_var_run_t);
files_read_etc_files(systemd_mailify_conf_t);
files_search_etc(systemd_mailify_conf_t);
files_pid_filetrans(systemd_mailify_t,systemd_mailify_var_run_t, { file });
auth_use_nsswitch(systemd_mailify_t);
logging_send_syslog_msg(systemd_mailify_t);
miscfiles_read_localization(systemd_mailify_t);
sysnet_dns_name_resolve(systemd_mailify_t);
allow systemd_mailify_exec_t smtp_port_t:tcp_socket name_connect;
corenet_tcp_sendrecv_all_if(systemd_mailify_exec_t);
corenet_tcp_sendrecv_all_nodes(systemd_mailify_exec_t);
corenet_tcp_sendrecv_all_ports(systemd_mailify_exec_t);
corenet_all_recvfrom_unlabeled(systemd_mailify_exec_t);
domain_use_interactive_fds(systemd_mailify_exec_t);
#######################
systemd-mailify.fc
#######################
/usr/bin/systemd-mailify.py --
gen_context(system_u:object_r:systemd_mailify_exec_t,s0)
/etc/systemd-mailify.conf
gen_context(system_u:object_r:systemd_mailify_conf_t,s0)
/usr/lib/systemd/system/systemd-mailify.service
gen_context(system_u:object_r:systemd_unit_file_t,s0)
/run/systemd-mailify.pid
gen_context(system_u:object_r:systemd_mailify_var_run_t,s0)
8 years, 11 months
