transition from init_rc
by Tracy Reed
I think I'm really close to having this policy finished and working, just a
couple things to work out...
When I exercise my app and then run audit2allow and it says:
#!!!! This avc is a constraint violation. You will need to add an attribute to either the source or target type to make it work.
#Contraint rule:
allow myapp_t default_t:dir search;
allow myapp_t default_t:dir read;
allow myapp_t default_t:file execmod;
allow myapp_t myapp_bin_t:file write;
does it mean only the first line is an constraint violation? Or are all of
those constraint violations?
How does one typically deal with constraint violations? By attribute above I
suppose it means a type attribue but how do I know which one to add?
Then I have these:
#!!!! This avc is a constraint violation. You will need to add an attribute to either the source or target type to make it work.
#Contraint rule:
allow initrc_t default_t:file relabelto;
#!!!! This avc is a constraint violation. You will need to add an attribute to either the source or target type to make it work.
#Contraint rule:
allow initrc_t myapp_api_t:file relabelto;
The init script which starts the service relabels the files when the service
starts. I suspect this is a bad idea and I'm not sure why they are doing it. I
think they may be applying security categories here. We may have to find a
different way to approach that.
But how would I allow this if I wanted to?
Similarly:
#!!!! This avc is a constraint violation. You will need to add an attribute to either the source or target type to make it work.
#Contraint rule:
allow setfiles_t default_t:file relabelfrom;
#!!!! This avc is a constraint violation. You will need to add an attribute to either the source or target type to make it work.
#Contraint rule:
allow setfiles_t myapp_api_t:file relabelfrom;
etc...
This is all on CentOS 6.5.
Thanks!
--
Tracy Reed
8 years
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, 6 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, 6 months
CentOS 7 selinux policy bug
by mark
Hi, folks,
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***** <...>
I did do an ll =Z /usr/bin, and everything looks correct
(system_u:object_r:bin_t:s0). Given that, looks to me like a policy bug.
No? Yes? File a bug report?
mark
8 years, 6 months
redirect stdout and stderr to different file under sandboxing in linux
by Bhuvan Gupta
Hello All,
I have an Test.cpp which is run under sandbox(RHEL7):
Test.cpp content:
#include<stdio>
int main(void) {
int a = 1/0;
return 0;
}
compile it using gcc(4.8) Test.cpp which produces the a.out
Now running a.out prints floating pointing exception on console
Now i thought that if i redirect stderr to a file, i expect the error to be
printed in file.
But that is not the case it still continue to print in console.
Googling reveal that under such exception the program is terminated
immediately and if you capture the stderr of bash then it should redirect.
So i run
*su -c ./a.out 2>err *
Bingo error get printed in err file.
Now the MAIN GAME STARTS
i want to run it under sandbox
so i run:
*su -c 'sandbox ./a.out 1>out 2>err'*
But there is nothing printed in err file or in console.
How to capture stdout and stderr under such situation ?
Thanks
Bhuvan
8 years, 6 months
Re: selinux enforcing and systemd-journald-dev-log.socket
by George Karakougioumtzis
Just an update i fixed this and i can boot properly. The only problems i
got so far are that loginctl doesnt show any sessions and polkit doesn't
work for either of my users(thats possibly a consequence of
systemd-logind not being able to identify the logged in users).
I got this:
systemd-logind[355]: Assertion 's->user->slice' failed at
../src/login/logind-session.c:496, function session_start_scope(). Aborting.
On 05/28/2015 03:11 PM, George Karakougioumtzis wrote:
> Hi. I am hit by the same exact bug as described here
> https://bugzilla.redhat.com/show_bug.cgi?id=1099299
>
> but this is an already upgraded f21 machine. The problem is i cant
> enforce selinux i have the boot loop described in the bug.
> I have upgraded initscripts and systemd as per the bug. I reinstalled
> selinux-policy-targeted just in case.
> All i get is a failure of systemd-journlad-dev-log.socket and both
> systemd-journald.service and systemd-udevd.service. Any hints? I already
> tried to autorelabel but that didnt fix it.
8 years, 6 months
selinux enforcing and systemd-journald-dev-log.socket
by George Karakougioumtzis
Hi. I am hit by the same exact bug as described here
https://bugzilla.redhat.com/show_bug.cgi?id=1099299
but this is an already upgraded f21 machine. The problem is i cant
enforce selinux i have the boot loop described in the bug.
I have upgraded initscripts and systemd as per the bug. I reinstalled
selinux-policy-targeted just in case.
All i get is a failure of systemd-journlad-dev-log.socket and both
systemd-journald.service and systemd-udevd.service. Any hints? I already
tried to autorelabel but that didnt fix it.
8 years, 6 months
Re: selinux process transition not taking place
by SZIGETVÁRI János
Yes, both executables in this case are shell scripts, so you're most likely
right. (*)
The original scenario seems different though, as the following conditions
are met there:
-- there is an init script with the context syslogd_initrc_exec_t, which
calls a
-- symlink under /opt/<product>/sbin which has the context of bin_t, and is
a reference for the
-- binary executable /opt/<product>/libexec/<executable> which has a
context of syslogd_exec_t.
Normally this setup works just fine, but one of our customers encountered a
situation where the daemon is stuck as initrc_t.
We have tried verifying every little detail, but we failed to spot any
differences between their environment, where the problem persists, and
ours, where everything works fine.
(*) I think, I will write a short C program in order to find out whether
this was in deed the main reason why my demo script failed to transition to
syslogd_t.
2015-05-18 20:34 GMT+02:00 Stephen Smalley <sds(a)tycho.nsa.gov>:
> On 05/15/2015 04:30 AM, SZIGETVÁRI János wrote:
> > Hello Again,
> >
> > I have managed to reproduce the problem on CentOS 7 as well, but due to
> > the exlusion of the run_init command, the script needed a bit of
> > tailoring as well.
> > I have attached the modified script. (To make up for the "lost"
> > run_init, the script has to have the
> > "system_u:object_r:run_init_exec_t:s0" context.)
> > Anyway, the problem's solution is more pressing on CentOS 6, so any help
> > or hints would be appreciated.
>
> Sorry, it looks like you are running the equivalent of:
> bash /path/to/script
> in each of your scripts.
>
> Which means exec bash and have it open the script file and read it, then
> interpret it. So we never call execve() on the script file and thus we
> never perform a domain transition. Is that what you were doing in your
> original situation too?
>
>
>
--
Janos SZIGETVARI
E-mail: jszigetvari(a)gmail.com
Phone: +36209440412 (Hungary)
__@__˚V˚
Make the switch to open (source) applications, protocols, formats now:
- windows -> Linux, iexplore -> Firefox, msoffice -> LibreOffice.org
- msn -> jabber protocol (Pidgin, Google Talk)
- mp3 -> ogg, wmv -> ogg, jpg -> png, doc/xls/ppt -> odt/ods/odp
8 years, 6 months
Fwd: selinux process transition not taking place
by SZIGETVÁRI János
2015-05-21 15:52 GMT+02:00 Stephen Smalley <sds(a)tycho.nsa.gov>:
> Wait, that denial shows that it was already running in syslogd_t and
> then tried to execute the script. execute_no_trans is when you try to
> execute something without changing contexts.
>
>
Yes, it surprises me too, and I don't seem to understand it either...
[root@centos-test aaa]# run_init /bin/bash
Authenticating root.
Password:
[root@centos-test /]# id
uid=0(root) gid=0(root) groups=0(root) context=system_u:system_r:initrc_t:s0
[root@centos-test /]# ps auxfZ | grep $$
system_u:system_r:initrc_t:s0 root 6357 0.0 0.1 108300 1888
pts/0 S 16:04 0:00 | \_ /bin/bash
system_u:system_r:initrc_t:s0 root 6369 0.0 0.0 103240 860
pts/0 S+ 16:04 0:00 | \_ grep 6357
[root@centos-test /]# ls -lZ /root/aaa/syslogd_exec_t_test.sh /bin/bash
-rwxr-xr-x. root root system_u:object_r:shell_exec_t:s0 /bin/bash
-rwxr-xr-x. root root system_u:object_r:syslogd_exec_t:s0
/root/aaa/syslogd_exec_t_test.sh
[root@centos-test /]# cat /root/aaa/syslogd_exec_t_test.sh
#!/bin/sh
export PATH="/bin:/usr/bin"
echo ${$}
ps auxfZ | fgrep -v grep | fgrep ${$}
[root@centos-test /]# /root/aaa/syslogd_exec_t_test.sh
/bin/sh: /root/aaa/syslogd_exec_t_test.sh: Permission denied
[root@centos-test /]# setenforce 0
[root@centos-test /]# /root/aaa/syslogd_exec_t_test.sh
6374
system_u:system_r:syslogd_t:s0 root 6374 0.0 0.0 106060 1340
pts/0 S+ 16:05 0:00 | \_ /bin/sh
/root/aaa/syslogd_exec_t_test.sh
[root@centos-test /]# setenforce 1
[root@centos-test /]# exit
8 years, 6 months
Fwd: selinux process transition not taking place
by SZIGETVÁRI János
2015-05-21 15:03 GMT+02:00 Stephen Smalley <sds(a)tycho.nsa.gov>:
> avc: denied message?
> Reproducible if you setenforce 0?
>
> In permissive mode it works, and the transition occurs.
/var/log/audit/audit.log:
type=AVC msg=audit(1432215103.845:327): avc: denied { execute_no_trans }
for pid=6209 comm="syslogd_exec_t_"
path="/root/aaa/syslogd_exec_t_runner.sh" dev=dm-0 ino=1441833
scontext=system_u:system_r:syslogd_t:s0
tcontext=system_u:object_r:syslogd_exec_t:s0 tclass=file
/var/log/messages:
May 21 15:31:48 centos-test setroubleshoot: SELinux is preventing /bin/bash
from execute_no_trans access on the file
/root/aaa/syslogd_exec_t_runner.sh. For complete SELinux messages. run
sealert -l b7a35e75-7b54-47c8-95df-534a261de98d
8 years, 6 months
