Bootup error with Selinux +F15
by magina antimage
Hi,
i have tried disabling SElinux ,because i didnt had selinux module
enabled in my kernel.
i have tried changing /etc/selinux/config:
from SELINUX=permissive to SELINUX=disabled
but still i get error
"Failed to load SELinux policy." during bootup
i have referred to "https://bugzilla.redhat.com/show_bug.cgi?id=692573 "
and tried to solve this problem, but no positive results
also sometimes i get I/O errors on my hard disk (during boot) after
one or two boots .
i am not sure whether its because of SElinux or not,but while
searching this I/O error i came across few cases where these I/O
errors were because of SElinux policies.
other details:
arch:x86
selinux version:libselinux-2.0.99-4.fc15.i686
10 years, 1 month
Re: SELinux, NIS, NFS, and /home, trouble with Fedora 18 converting
user_home_dir_t to detault_t
by Roland Roberts
For reasons I don't understand, the install labelled /home with (I think, I'm offsite with no access) auto_fs_t as it is a mount point for autofs.
Roland
--
Roland Roberts, PhD
6818 Madeline Court
Brooklyn, NY 11220
-------- Original message --------
From: Daniel J Walsh <dwalsh(a)redhat.com>
Date: 05/28/2013 8:33 AM (GMT-05:00)
To: Roland Roberts <roland(a)astrofoto.org>
Cc: Dominick Grift <dominick.grift(a)gmail.com>,selinux(a)lists.fedoraproject.org
Subject: Re: SELinux, NIS, NFS, and /home, trouble with Fedora 18 converting
user_home_dir_t to detault_t
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 05/28/2013 08:03 AM, Roland Roberts wrote:
> Yet normally /home is home_root_t. And in my case /data is a mount point
> for other things; the actual disk is mounted at /data/home, so I thought I
> was doing the equivalent of what the man page says.
>
> Roland -- Roland Roberts, PhD 6818 Madeline Court Brooklyn, NY 11220
>
>
>
> -------- Original message -------- From: Dominick Grift
> <dominick.grift(a)gmail.com> Date: 05/28/2013 4:13 AM (GMT-05:00) To: Roland
> Roberts <roland(a)astrofoto.org> Cc: selinux(a)lists.fedoraproject.org Subject:
> Re: SELinux, NIS, NFS, and /home, trouble with Fedora 18 converting
> user_home_dir_t to detault_t
>
>
> On Mon, 2013-05-27 at 19:01 -0400, Roland Roberts wrote:
>
> SELinux contexts for /home are treated a bit differently than other
> locations.
>
> Try instead: (from: man semanage):
>
>> For home directories under top level directory, for example /disk6/home,
>> execute the following commands. # semanage fcontext -a -t home_root_t
>> "/disk6" # semanage fcontext -a -e /home /disk6/home # restorecon -R -v
>> /disk6
>
>
>> I'm trying to clean up selinux contexts and having trouble. The system is
>> a new install of Fedora 18, but the home directories have been preserved
>> for a long time. Because the system runs boot on raid-1, it was installed
>> as Fedora 17 and then I used fedup to move to Fedora 18.
>>
>> My home directories are automounted via NFS and an NIS map. I mount them
>> on the clients with an explicit context:
>>
>> 270 roland> ypcat auto.home
>> -rw,soft,intr,tcp,context="system_u:object_r:user_home_t:s0"
>> archos.rlent.pnet:/data/home/&
>>
>> However, my troubles right now are confined to the server.
>>
>> The real home directory is /data/home so /data/home/roland is mounted on
>> /home/roland. All clients see the same mount point, even the server
>> remounts this way.
>>
>> Most of the selinux context information is wrong, probably because some
>> of these files have been hanging around roughly since RedHat 3.0.3. Yes,
>> really. Although the content has surely changed (e.g., .bashrc).
>>
>> To get started, I've done this
>>
>> semanage fcontext -a -t home_root_t /data/home semanage fcontext -a -t
>> user_home_dir_t '/data/home/(.*)' semanage fcontext -a -t lost_found_t
>> /data/home/lost+found restorecon -v -R /data/home
>>
>> That gave the surprising result of doing absolutely nothing. So I
>> brute-forced it and did
>>
>> semanage fcontext -a -t home_root_t /data/home semanage fcontext -a -t
>> lost_found_t /data/home/lost+found for D in $LIST; do semanage fcontext
>> -a -t user_home_dir_t /data/home/$D; done restorecon -v -R /data/home
>>
>> The above did not work for the lost+found directory. I haven't figured
>> out why. I tried deleting all the contexts I had set and starting over
>> and I tried setting the context just on lost+found repeatedly to no
>> avail. lost+found remains default_t.
>>
>> Next, I log in via ssh to my user account. Since I have X forwarding
>> turned on, this results in an .Xauthority file being created. If I run
>> (as root, from another window) restorecon, I get this
>>
>> [root@archos ~]# cd /data/home/roland [root@archos roland]# restorecon -v
>> -R /data/home/roland restorecon reset /data/home/roland/.Xauthority
>> context
>> unconfined_u:object_r:xauth_home_t:s0->unconfined_u:object_r:default_t:s0
>>
>>
>>
So the file was created with the correct context, but it gets zapped
>> with restorecon. I can create a new file via touch and it gets created
>> with the correct context
>>
>> 268 roland> ls -Z foo -rw-rw-r--. roland roland
>> unconfined_u:object_r:user_home_t:s0 foo 269 roland> ls -Zad .
>> drwxr-xr-x. roland roland system_u:object_r:user_home_dir_t:s0 .
>>
>> But again, if I run restorecon, it gets converted to default_t.
>>
>> I realize the whole NIS/NFS thing makes this problematic on the clients,
>> but all of the above is on the server. I was hoping to get the file
>> contexts fixed up, but even if I can get it to stop converting everything
>> back to default_t, I haven't got a clue about all the other contexts I
>> need to set (e.g., ssh_home_t for .ssh, but what else) and then I fear
>> they will just get reset, too.
>>
>> So, what's going on here and how do I stop it? Then after that, how do I
>> go about fixing all the default_t under my home directory to be what they
>> should be.
>>
>> roland
>>
>
>
>
>
> -- selinux mailing list selinux(a)lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/selinux
>
In this case you want to label /data/home as equivalent to /home
and you probably want to label data with a label that most apps can read like
usr_t.
# semanage fcontext -a -t usr_t '/data(/.*)?'
# semanage fcontext -a -e /home /data/home
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.13 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iEYEARECAAYFAlGkpAIACgkQrlYvE4MpobMKdgCgyvOOSlMo+7wSO7qB52SMHFRT
vUwAoIXc15OzcmadYZC+NANqMxKRSCve
=EBci
-----END PGP SIGNATURE-----
10 years, 4 months
Awstats search access denied
by Geert Janssens
Hi,
I have updated my Centos 6 installation a couple of days ago to include the most recent
packages.
Since that moment my awstats cron job is not working anymore. This cron job reads apache
log files and generates statistics for this.
Here is a sample of the avc I get:
----
time->Sat May 25 10:01:07 2013
type=PATH msg=audit(1369468867.049:94733): item=1 name=(null) inode=5832775
dev=ca:00 mode=040755 ouid=0 ogid=0 rdev=00:00
obj=system_u:object_r:httpd_sys_content_t:s0
type=PATH msg=audit(1369468867.049:94733): item=0
name="/var/www/hosting/iyoga.be/log/access_log"
type=CWD msg=audit(1369468867.049:94733): cwd="/"
type=SYSCALL msg=audit(1369468867.049:94733): arch=c000003e syscall=2 success=no
exit=-13 a0=2cc6490 a1=0 a2=1b6 a3=37b751dd40 items=2 ppid=7229 pid=7230 auid=0
uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=2826
comm="awstats.pl" exe="/usr/bin/perl" subj=system_u:system_r:awstats_t:s0-s0:c0.c1023
key=(null)
type=AVC msg=audit(1369468867.049:94733): avc: denied { search } for pid=7230
comm="awstats.pl" name="www" dev=xvda ino=5832775
scontext=system_u:system_r:awstats_t:s0-s0:c0.c1023
tcontext=system_u:object_r:httpd_sys_content_t:s0 tclass=dir
----
In /var/log/messages the corresponding message is:
May 25 10:01:12 abmpub6 setroubleshoot: SELinux is preventing /usr/bin/perl from search
access on the directory /var/www/hosting/iyoga.be/log/access_log. For complete SELinux
messages.
run sealert -l cb05aa4b-3270-49e5-be6f-37c8a6cadc56
The first oddity to note is that /var/www/hosting/iyoga.be/log/access_log is not a directory,
but a file.
Next I'm confused with the labels. The file is labeled system_u:object_r:httpd_log_t:s0, but the
avc seems to complain about system_u:object_r:httpd_sys_content_t:s0
Currently installed packages:
selinux-policy-targeted-3.7.19-195.el6_4.5.noarch
awstats-7.0-3.el6.noarch
I have no idea what happens here, let alone how to fix it. Can anyone shed some more light
on this ?
Thank you,
Geert
10 years, 4 months
avc_has_perm_noaudit crashes process after switching enforcing modes
by Steve Ross
Subscribers,
I'm a newbie. I hope that my question is appropriate for this forum.
I'm using "libselinux-2.094-5.2.el6.i686" from CentOS 6.2 on a system.
In particular, I'm using a call to "avc_has_perm_noaudit()". When
SELinux is in Enforcing mode, all is well and calls to the function
return the correct value of zero or -1. However, as the program runs,
when I externally (i.e., outside of the program's code, using
"setenforce") switch from Enforcing to Permissive, the next call to
"avc_has_perm_noaudit()" crashes the program. I would expect the
function to always return a zero in Permissive mode and not crash.
I've also seen that the call crashes my program if the system is in
Enforcing, I switch it to Permissive (but avoid calling
"avc_has_perm_noaudit()" by use of "security_getenforce()") and then
switch back to Enforcing and call the function.
Is it appropriate to call "avc_has_perm_noaudit()" after externally
switching enforcing modes? Is this crashing a known issue? Is it fixed
in a later release? (I've haven't tried any of the updated releases
listed at <http://userspace.selinuxproject.org/trac/wiki/Releases>.)
Thanks in advance for any help,
-- Steve Ross
10 years, 4 months
Re: SELinux, NIS, NFS, and /home, trouble with Fedora 18 converting
user_home_dir_t to detault_t
by Roland Roberts
Yet normally /home is home_root_t. And in my case /data is a mount point for other things; the actual disk is mounted at /data/home, so I thought I was doing the equivalent of what the man page says.
Roland
--
Roland Roberts, PhD
6818 Madeline Court
Brooklyn, NY 11220
-------- Original message --------
From: Dominick Grift <dominick.grift(a)gmail.com>
Date: 05/28/2013 4:13 AM (GMT-05:00)
To: Roland Roberts <roland(a)astrofoto.org>
Cc: selinux(a)lists.fedoraproject.org
Subject: Re: SELinux, NIS, NFS, and /home, trouble with Fedora 18 converting
user_home_dir_t to detault_t
On Mon, 2013-05-27 at 19:01 -0400, Roland Roberts wrote:
SELinux contexts for /home are treated a bit differently than other
locations.
Try instead: (from: man semanage):
> For home directories under top level directory, for example /disk6/home,
> execute the following commands.
> # semanage fcontext -a -t home_root_t "/disk6"
> # semanage fcontext -a -e /home /disk6/home
> # restorecon -R -v /disk6
> I'm trying to clean up selinux contexts and having trouble. The system
> is a new install of Fedora 18, but the home directories have been
> preserved for a long time. Because the system runs boot on raid-1, it
> was installed as Fedora 17 and then I used fedup to move to Fedora 18.
>
> My home directories are automounted via NFS and an NIS map. I mount them
> on the clients with an explicit context:
>
> 270 roland> ypcat auto.home
> -rw,soft,intr,tcp,context="system_u:object_r:user_home_t:s0"
> archos.rlent.pnet:/data/home/&
>
> However, my troubles right now are confined to the server.
>
> The real home directory is /data/home so /data/home/roland is mounted on
> /home/roland. All clients see the same mount point, even the server
> remounts this way.
>
> Most of the selinux context information is wrong, probably because some
> of these files have been hanging around roughly since RedHat 3.0.3. Yes,
> really. Although the content has surely changed (e.g., .bashrc).
>
> To get started, I've done this
>
> semanage fcontext -a -t home_root_t /data/home
> semanage fcontext -a -t user_home_dir_t '/data/home/(.*)'
> semanage fcontext -a -t lost_found_t /data/home/lost+found
> restorecon -v -R /data/home
>
> That gave the surprising result of doing absolutely nothing. So I
> brute-forced it and did
>
> semanage fcontext -a -t home_root_t /data/home
> semanage fcontext -a -t lost_found_t /data/home/lost+found
> for D in $LIST; do semanage fcontext -a -t user_home_dir_t
> /data/home/$D; done
> restorecon -v -R /data/home
>
> The above did not work for the lost+found directory. I haven't figured
> out why. I tried deleting all the contexts I had set and starting over
> and I tried setting the context just on lost+found repeatedly to no
> avail. lost+found remains default_t.
>
> Next, I log in via ssh to my user account. Since I have X forwarding
> turned on, this results in an .Xauthority file being created. If I run
> (as root, from another window) restorecon, I get this
>
> [root@archos ~]# cd /data/home/roland
> [root@archos roland]# restorecon -v -R /data/home/roland
> restorecon reset /data/home/roland/.Xauthority context
> unconfined_u:object_r:xauth_home_t:s0->unconfined_u:object_r:default_t:s0
>
> So the file was created with the correct context, but it gets zapped
> with restorecon. I can create a new file via touch and it gets created
> with the correct context
>
> 268 roland> ls -Z foo
> -rw-rw-r--. roland roland unconfined_u:object_r:user_home_t:s0 foo
> 269 roland> ls -Zad .
> drwxr-xr-x. roland roland system_u:object_r:user_home_dir_t:s0 .
>
> But again, if I run restorecon, it gets converted to default_t.
>
> I realize the whole NIS/NFS thing makes this problematic on the clients,
> but all of the above is on the server. I was hoping to get the file
> contexts fixed up, but even if I can get it to stop converting
> everything back to default_t, I haven't got a clue about all the other
> contexts I need to set (e.g., ssh_home_t for .ssh, but what else) and
> then I fear they will just get reset, too.
>
> So, what's going on here and how do I stop it? Then after that, how do I
> go about fixing all the default_t under my home directory to be what
> they should be.
>
> roland
>
10 years, 4 months
How to fix cron Fedora 18
by Frank Murphy
The following showing up fron one box.
The box is enforcing, system-config-selinux shows as such.
What do I need to fix, or is cron meant to be permissive.?
--------------------- Cron Begin ------------------------
**Unmatched Entries**
NULL security context for user, but SELinux in permissive mode,
continuing () Unauthorized SELinux
context=unconfined_u:unconfined_r:unconfined_t:s0
file_context=unconfined_u:object_r:user_cron_spool_t:s0
(/var/spool/cron/root) SELinux in permissive mode, continuing
(/var/spool/cron/root) Unauthorized SELinux
context=unconfined_u:unconfined_r:unconfined_t:s0
file_context=unconfined_u:object_r:user_cron_spool_t:s0
(/var/spool/cron/root) SELinux in permissive mode, continuing
(/var/spool/cron/root) NULL security context for user, but SELinux in
permissive mode, continuing () NULL security context for user, but
SELinux in permissive mode, continuing () NULL security context for
user, but SELinux in permissive mode, continuing () NULL security
context for user, but SELinux in permissive mode, continuing ()
---------------------- Cron End -------------------------
--
Regards,
Frank - I check for new mail app. 20min
www.frankly3d.com
10 years, 4 months
SELinux, NIS, NFS, and /home, trouble with Fedora 18 converting user_home_dir_t to detault_t
by Roland Roberts
I'm trying to clean up selinux contexts and having trouble. The system
is a new install of Fedora 18, but the home directories have been
preserved for a long time. Because the system runs boot on raid-1, it
was installed as Fedora 17 and then I used fedup to move to Fedora 18.
My home directories are automounted via NFS and an NIS map. I mount them
on the clients with an explicit context:
270 roland> ypcat auto.home
-rw,soft,intr,tcp,context="system_u:object_r:user_home_t:s0"
archos.rlent.pnet:/data/home/&
However, my troubles right now are confined to the server.
The real home directory is /data/home so /data/home/roland is mounted on
/home/roland. All clients see the same mount point, even the server
remounts this way.
Most of the selinux context information is wrong, probably because some
of these files have been hanging around roughly since RedHat 3.0.3. Yes,
really. Although the content has surely changed (e.g., .bashrc).
To get started, I've done this
semanage fcontext -a -t home_root_t /data/home
semanage fcontext -a -t user_home_dir_t '/data/home/(.*)'
semanage fcontext -a -t lost_found_t /data/home/lost+found
restorecon -v -R /data/home
That gave the surprising result of doing absolutely nothing. So I
brute-forced it and did
semanage fcontext -a -t home_root_t /data/home
semanage fcontext -a -t lost_found_t /data/home/lost+found
for D in $LIST; do semanage fcontext -a -t user_home_dir_t
/data/home/$D; done
restorecon -v -R /data/home
The above did not work for the lost+found directory. I haven't figured
out why. I tried deleting all the contexts I had set and starting over
and I tried setting the context just on lost+found repeatedly to no
avail. lost+found remains default_t.
Next, I log in via ssh to my user account. Since I have X forwarding
turned on, this results in an .Xauthority file being created. If I run
(as root, from another window) restorecon, I get this
[root@archos ~]# cd /data/home/roland
[root@archos roland]# restorecon -v -R /data/home/roland
restorecon reset /data/home/roland/.Xauthority context
unconfined_u:object_r:xauth_home_t:s0->unconfined_u:object_r:default_t:s0
So the file was created with the correct context, but it gets zapped
with restorecon. I can create a new file via touch and it gets created
with the correct context
268 roland> ls -Z foo
-rw-rw-r--. roland roland unconfined_u:object_r:user_home_t:s0 foo
269 roland> ls -Zad .
drwxr-xr-x. roland roland system_u:object_r:user_home_dir_t:s0 .
But again, if I run restorecon, it gets converted to default_t.
I realize the whole NIS/NFS thing makes this problematic on the clients,
but all of the above is on the server. I was hoping to get the file
contexts fixed up, but even if I can get it to stop converting
everything back to default_t, I haven't got a clue about all the other
contexts I need to set (e.g., ssh_home_t for .ssh, but what else) and
then I fear they will just get reset, too.
So, what's going on here and how do I stop it? Then after that, how do I
go about fixing all the default_t under my home directory to be what
they should be.
roland
--
PGP Key ID: 66 BC 3B CD
Roland B. Roberts, PhD RL Enterprises
roland(a)rlenter.com 6818 Madeline Court
roland(a)astrofoto.org Brooklyn, NY 11220
10 years, 4 months
constraint violation problem
by Thorsten Scherf
Following setup:
iucv instance is started via upstart to make iucv connections available
in a z/VM environment:
# cat /etc/init/iucv.conf
start on runlevel [2345]
stop on runlevel [01]
respawn
exec /usr/bin/iucvtty lnxterm
iucvtty is running in init_t:
# ps -efZ|grep iucv
system_u:system_r:init_t:s0 root 1788 1 0 13:56 ? 00:00:00 /usr/bin/iucvtty lnxterm
Using ts-shell to connect from a central server to this system produces
the following AVC:
type=AVC msg=audit(1368960989.210:22183): avc: denied { transition }
for pid=1761 comm="login" path="/bin/bash" dev=dasda3 ino=379
scontext=system_u:system_r:local_login_t:s0
tcontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
tclass=process
type=SYSCALL msg=audit(1368960989.210:22183): arch=80000016 syscall=11
per=400000 success=yes exit=11 a0=b6070570 a1=3fffffbd920 a2=b6083870
a3=4a42fac3a0 items=0 ppid=1756 pid=1761 auid=500 uid=500 gid=500
euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 tty=pts1 ses=3
comm="bash" exe="/bin/bash"
subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key=(null)
This is the output from audit2allow:
#!!!! 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 local_login_t unconfined_t:process transition;
What is the recommended way to avoid this AVC?
Cheers,
Thorsten
10 years, 4 months
Zoneminder and Selinux and the Infinite Story of Doom
by Tristan Santore
Dear All,
For the last few days Dominick and I have been trying to write a policy
for Zoneminder, as the current policy does not seem to be working.
I will append what we gathered up so far below, however before I do,
there seems to be an inherent problem with apache and sudo/su/pam, which
seems to work in permissive mode, but as soon as I enable enforcing,
b00m, I get these.
May 21 14:18:23 hq su: pam_unix(su:auth): auth could not identify
password for [apache]
May 21 14:18:23 hq su: pam_succeed_if(su:auth): requirement "uid >=
1000" not met by user "apache"
May 21 14:18:23 hq su: pam_unix(su:auth): auth could not identify
password for [apache]
May 21 14:18:23 hq su: pam_succeed_if(su:auth): requirement "uid >=
1000" not met by user "apache"
In permissive mode all is fine:
May 21 14:32:03 hq su: pam_unix(su:session): session opened for user
apache by (uid=0)
May 21 14:32:03 hq su: pam_unix(su:session): session closed for user apache
May 21 14:32:03 hq su: pam_unix(su:session): session opened for user
apache by (uid=0)
May 21 14:32:03 hq su: pam_unix(su:session): session closed for user apache
May 21 14:32:03 hq su: pam_unix(su:session): session opened for user
apache by (uid=0)
type=USER_CMD msg=audit(1369143877.597:513): pid=2196 uid=0
auid=4294967295 ses=4294967295 subj=system_u:system_r:zoneminder_t:s0
msg='cwd="/usr/share/zoneminder/www" cmd="true" terminal=? res=failed'
type=USER_AUTH msg=audit(1369143877.611:514): pid=2197 uid=0
auid=4294967295 ses=4294967295 subj=system_u:system_r:zoneminder_t:s0
msg='op=PAM:authentication acct="apache" exe="/usr/bin/su" hostname=?
addr=? terminal=? res=failed'
type=USER_AUTH msg=audit(1369143877.625:515): pid=2199 uid=0
auid=4294967295 ses=4294967295 subj=system_u:system_r:zoneminder_t:s0
msg='op=PAM:authentication acct="apache" exe="/usr/bin/su" hostname=?
addr=? terminal=? res=failed'
type=SERVICE_START msg=audit(1369143877.642:516): pid=1 uid=0
auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='
comm="zoneminder" exe="/usr/lib/systemd/systemd" hostname=? addr=?
terminal=? res=failed'
Any insights would be most appreciated, as I would really like to see a
policy for zoneminder that works, not only for myself, but so that we
can have it in the Fedora stock policy.
Thank you for all your help, especially Dominick Grift's.
Regards,
Tristan
And the policy we have so far:
policy_module(myzonem, 1.0.0)
gen_require(` type zoneminder_t; ')
domain_read_all_domains_state(zoneminder_t)
logging_send_audit_msgs(zoneminder_t)
sudo_exec(zoneminder_t)
su_exec(zoneminder_t)
allow zoneminder_t self:process setrlimit;
allow zoneminder_t self:capability { setuid setgid sys_resource };
gen_require(`type httpd_zoneminder_script_exec_t; ')
can_exec(zoneminder_t, httpd_zoneminder_script_exec_t)
gen_require(` type zoneminder_var_lib_t; ')
manage_lnk_files_pattern(zoneminder_t, zoneminder_var_lib_t,
zoneminder_var_lib_t)
dbus_system_bus_client(zoneminder_t)
selinux_compute_access_vector(zoneminder_t)
allow zoneminder_t self:process setsched;
allow zoneminder_t self:key write;
auth_rw_lastlog(zoneminder_t)
systemd_write_inherited_logind_sessions_pipes(zoneminder_t)
auth_domtrans_chk_passwd(zoneminder_t)
systemd_dbus_chat_logind(zoneminder_t)
gen_require(` type chkpwd_t; ')
allow zoneminder_t chkpwd_t:process { rlimitinh noatsecure siginh };
auth_read_shadow(zoneminder_t)
auth_domtrans_upd_passwd(zoneminder_t)
#gen_require(` type systemd_logind_t; ')
#permissive systemd_logind_t;
gen_require(` type unconfined_t; role system_r; type zoneminder_exec_t;
role unconfined_r; ')
domtrans_pattern(unconfined_t, zoneminder_exec_t, zoneminder_t)
role_transition unconfined_r zoneminder_exec_t:file system_r;
domain_entry_file(zoneminder_t, httpd_zoneminder_script_exec_t)
domtrans_pattern(unconfined_t, httpd_zoneminder_script_exec_t, zoneminder_t)
gen_require(` type httpd_t; ')
gen_require(` type httpd_zoneminder_script_t; type zoneminder_tmpfs_t;')
init_read_utmp(httpd_t)
read_files_pattern(httpd_t, zoneminder_var_lib_t, zoneminder_var_lib_t)
rw_files_pattern(httpd_zoneminder_script_t, zoneminder_tmpfs_t,
zoneminder_tmpfs_t)
manage_dirs_pattern(httpd_zoneminder_script_t, zoneminder_var_lib_t,
zoneminder_var_lib_t)
manage_files_pattern(httpd_zoneminder_script_t, zoneminder_var_lib_t,
zoneminder_var_lib_t)
allow httpd_t zoneminder_var_lib_t:dir list_dir_perms;
init_daemon_domain(zoneminder_t, httpd_zoneminder_script_exec_t)
require {
type chkpwd_t;
type httpd_t;
type httpd_zoneminder_script_t;
type sshd_t;
class process { siginh noatsecure rlimitinh };
class unix_stream_socket { read write };
}
#============= httpd_t ==============
allow httpd_t httpd_zoneminder_script_t:process { siginh noatsecure
rlimitinh };
#============= httpd_zoneminder_script_t ==============
allow httpd_zoneminder_script_t httpd_t:unix_stream_socket { read write };
require {
type passwd_t;
}
allow passwd_t chkpwd_t:process { noatsecure siginh rlimitinh };
allow httpd_zoneminder_script_t httpd_t:unix_stream_socket { read write };
allow httpd_t httpd_zoneminder_script_t:process { noatsecure siginh
rlimitinh };
--
Tristan Santore BSc MBCS
TS4523-RIPE
Network and Infrastructure Operations
InterNexusConnect
Mobile +44-78-55069812
Tristan.Santore(a)internexusconnect.net
Former Thawte Notary
(Please note: Thawte has closed its WoT programme down,
and I am therefore no longer able to accredit trust)
For Fedora related issues, please email me at:
TSantore(a)fedoraproject.org
10 years, 4 months
