VASD policy
by Vadym Chepkov
Hi,
I noticed just one vasd related entry found it's way into SELinux policy:
# grep vasd ./serefpolicy-3.7.19/policy/modules/system/authlogin.fc
/var/opt/quest/vas/vasd(/.*)? gen_context(system_u:object_r:var_auth_t,s0)
vasd is part of Quest Auth Services and I wonder if somebody already has a
policy defined for it or I have to start from scratch. Quest suggested to
disable SELinux, of cause.
Thanks,
Vadym
9 years, 10 months
postgresql and nfs
by mark
CentOS 6.4
selinux-policy-targeted-3.7.19-195.el6_4.12.noarch
Permissive (of course)
postgresql is trying to read on an nfs-mounted directory. setsebool
allow_user_postgresql_connect on
use_nfs_home_dirs --> on
And if I use audit2allow, it wants to make a policy of
#============= postgresql_t ==============
allow postgresql_t nfs_t:dir search;
Should there be a boolean, or is this a policy oversight? And in the
meantime, should I just make the local policy?
mark
10 years, 2 months
libvirt can not start vm
by bigclouds
hi,all
if i disable selinux at the moment, does this error matter?
type=VIRT_CONTROL msg=audit(1379823101.861:1278): user pid=3007 uid=0 auid=0 ses=15 msg='virt=kvm op=start reason=booted vm="testname-1" uuid=24f7e975-9aa5-4a14-b0f0-590add14c8b5 vm-pid=-1 exe="/usr/sbin/libvirtd" hostname=? addr=? terminal=? res=failed'
libvirtd can not start vm, but i can start throught command line which is getten from libvirtd.log.
10 years, 2 months
Avcs for spamc
by David Highley
The avcs listed below seem to have been around for a long time. Is pyzor
really trying to run rpm to install something?
type=SYSCALL msg=audit(1376212087.230:525): arch=c000003e syscall=4
success=no e
xit=-13 a0=24121b0 a1=7fff9e82e820 a2=7fff9e82e820 a3=7f889c8a35d0
items=0 ppid=9709 pid=9710 auid=4294967295 uid=0 gid=0 euid=0 suid=0
fsuid=0 egid=0 sgid=0 fsgid=0 ses=4294967295 tty=(none) comm="pyzor"
exe="/usr/bin/python2.7" subj=system_u:system_r:spamc_t:s0 key=(null)
type=AVC msg=audit(1376212087.230:525): avc: denied { getattr } for
pid=9710 comm="pyzor" path="/usr/bin/rpm" dev="dm-1" ino=691636
scontext=system_u:system_r:spamc_t:s0
tcontext=system_u:object_r:rpm_exec_t:s0 tclass=file
type=SYSCALL msg=audit(1376217670.157:605): arch=c000003e syscall=4
success=no exit=-13 a0=1b511b0 a1=7fffab9ca4a0 a2=7fffab9ca4a0
a3=7fafd093b5d0 items=0 ppid=10665 pid=12274 auid=4294967295 uid=0 gid=0
euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 ses=4294967295 tty=(none)
comm="pyzor" exe="/usr/bin/python2.7" subj=system_u:system_r:spamc_t:s0
key=(null)
type=AVC msg=audit(1376217670.157:605): avc: denied { getattr } for
pid=12274 comm="pyzor" path="/usr/bin/rpm" dev="dm-1" ino=691636
scontext=system_u:system_r:spamc_t:s0
tcontext=system_u:object_r:rpm_exec_t:s0 tclass=file
type=SYSCALL msg=audit(1376218163.947:614): arch=c000003e syscall=4
success=no exit=-13 a0=1d191b0 a1=7fff04d2fd70 a2=7fff04d2fd70
a3=35101c15d0 items=0 ppid=24224 pid=24226 auid=4294967295 uid=0 gid=0
euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 ses=4294967295 tty=(none)
comm="pyzor" exe="/usr/bin/python2.7" subj=system_u:system_r:spamc_t:s0
key=(null)
type=AVC msg=audit(1376218163.947:614): avc: denied { getattr } for
pid=24226 comm="pyzor" path="/usr/bin/rpm" dev="dm-1" ino=9914
scontext=system_u:system_r:spamc_t:s0
tcontext=system_u:object_r:rpm_exec_t:s0 tclass=file
10 years, 2 months
fail2ban with ipset fails when selinux enforceing?
by Charles Bradshaw
I'm running Fedora 17, kernel 3.9.10-100.fc17.i686.PAE
I am configuring ipset as an addition to fail2ban which I have had working for some time.
I have this fail2ban-fixes.te compiled and installed:
module fail2ban-fixes 1.02;
# created using:
# cat /var/log/audit/audit.log | audit2allow -m local > local.te
# and moving local.te here.
#
# Modification:
# 1.00 May 28 2013 fail2ban_client_t
# 1.01 Jun 15 2013 logrotate_t
# 1.02 Sep 16 2013 fail2ban_t
# 1.00 - allow fail2ban client access to http logs
#
require {
type httpd_log_t;
type fail2ban_var_run_t;
type fail2ban_client_t;
class di31.7.144.66r { read write search };
}
#============= fail2ban_client_t ==============
allow fail2ban_client_t fail2ban_var_run_t:dir write;
allow fail2ban_client_t httpd_log_t:dir read;
allow fail2ban_client_t httpd_log_t:dir search;
# 1.01 - allow fail2ban logrotate
#
require {
type logrotate_t;
type fail2ban_client_exec_t;
class file { read execute open };
}
#============= logrotate_t ==============
allow logrotate_t fail2ban_client_exec_t:file { read execute };
# 1.02 allow fail2ban access to ipset NOT WORKING when enforcing !
#
require {
type fail2ban_t;
class netlink_socket { bind create getattr };
class capability net_admin;
}
#============= fail2ban_t ==============
allow fail2ban_t self:netlink_socket { bind create getattr };
allow fail2ban_t self:capability net_admin;
All of the above have been created using audit2allow.
The last block of the above, 'fail2ban_t', is necessary to get ipset to work the previous were
necessary to allow the fail2ban client.
As long as I am in permissive mode there are NO failed records in /var/log/audit/audit.log and
'nothing to do' reported by audit2allow.
The ipset command is:
ipset --test fail2ban-forum 198.143.143.5 || ipset --add fail2ban-forum 198.143.143.5
and the correct entry is made to the hash:ip set fail2ban-forum. (that is as long as we are permissive)
However, when enforcing is enabled the fail2ban.log contains errors like this:
2013-09-16 21:32:24,750 fail2ban.actions.action: ERROR ipset --test fail2ban-forum 198.143.143.5 || ipset --add fail2ban-forum 198.143.143.5 returned 100
I can, of course, execute the ipset commands as root when enforcing.
Here's the problem:
There is nothing in /var/log/audit/audit.log or /var/log/messages to diagnose the nature of the error!
Where is the bug? selinux or ipset or somewhere else?
How do I debug the problem?
Any clues much appreciated. I am cross posting this to the fail2ban list.
TIA Charles Bradshaw
10 years, 2 months
Re: Why do matchpathcon and restorecon ignore the user context by default? - solved
by Bram Mertens
On Wed, Jul 31, 2013 at 11:18 PM, Daniel J Walsh <dwalsh(a)redhat.com> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 07/31/2013 03:13 PM, Bram Mertens wrote:
>> On Wed, Jul 31, 2013 at 7:11 PM, Daniel J Walsh <dwalsh(a)redhat.com> wrote:
>> On 07/31/2013 12:55 PM, Bram Mertens wrote:
>>>>> Hi,
>>>>>
>>>>> I have just lost several hours trying to figure out why I was unable
>>>>> to deploy a file from a configuration channel in our satellite server
>>>>> to a RHEL6 box while it deployed perfectly to a RHEL5 box.
>>>>>
>>>>> I finally tracked it down to the fact that the user context was set
>>>>> to unconfined_u while the rest of the context was set correctly.
>>>>>
>>>>> On RHEL5 rhncfg-client get worked flawlessly and deployed the file
>>>>> with a *different* user context (system_u) without complaining. On
>>>>> RHEL6 chncfg-client crashed complaining about the SElinux context -
>>>>> which differed only in the user context.
>>>>>
>>>>> Here's what I found (I also posted this as a follow up on the
>>>>> rhn-satellite mailing list):
>>>>>
>>>>> I see some very strange behaviour of SELinux on this RHEL6 box.
>>>>>
>>>>> on RHEL5 the following works as expected:
>>>>>
>>>>> The default SELinux security context for /etc/sssd/sssd.conf is:
>>>>> [mertensb@testadintegration01 ~]$ sudo /usr/sbin/matchpathcon
>>>>> /etc/sssd/sssd.conf /etc/sssd/sssd.conf system_u:object_r:etc_t
>>>>>
>>>>> Which is also what is currently applied:
>>>>> [mertensb@testadintegration01 ~]$ sudo ls -lZ /etc/sssd/sssd.conf
>>>>> -rw------- root root system_u:object_r:etc_t
>>>>> /etc/sssd/sssd.conf
>>>>>
>>>>> So matchpathcon is able to verify the context.
>>>>> [mertensb@testadintegration01 ~]$ sudo /usr/sbin/matchpathcon -V
>>>>> /etc/sssd/sssd.conf /etc/sssd/sssd.conf verified.
>>>>>
>>>>> Testing a randomn other file to verify that matchpathcon works:
>>>>> [mertensb@testadintegration01 ~]$ touch /tmp/proftpd
>>>>> [mertensb@testadintegration01 ~]$ sudo ls -lZ /tmp/proftpd
>>>>> -rw-rw-r-- mertensb mertensb user_u:object_r:tmp_t
>>>>> /tmp/proftpd [mertensb@testadintegration01 ~]$ sudo mv /tmp/proftpd
>>>>> /etc/cron.monthly/proftpd [mertensb@testadintegration01 ~]$ sudo ls
>>>>> -lZ /etc/cron.monthly/proftpd -rw-rw-r-- mertensb mertensb
>>>>> user_u:object_r:tmp_t /etc/cron.monthly/proftpd
>>>>> [mertensb@testadintegration01 ~]$ sudo /usr/sbin/matchpathcon
>>>>> /etc/cron.monthly/proftpd /etc/cron.monthly/proftpd
>>>>> system_u:object_r:ftpd_exec_t [mertensb@testadintegration01 ~]$ sudo
>>>>> /usr/sbin/matchpathcon -V /etc/cron.monthly/proftpd
>>>>> /etc/cron.monthly/proftpd has context user_u:object_r:tmp_t, should
>>>>> be system_u:object_r:ftpd_exec_t
>>>>>
>>>>> But on the RHEL6 machine I get: [mertensb@defrltot002 ~]$ sudo ls
>>>>> -lZ /etc/sssd/sssd.conf -rw-------. root root
>>>>> unconfined_u:object_r:etc_t:s0 /etc/sssd/sssd.conf
>>>>> [mertensb@defrltot002 ~]$ sudo /usr/sbin/matchpathcon
>>>>> /etc/sssd/sssd.conf /etc/sssd/sssd.conf
>>>>> system_u:object_r:etc_t:s0 [mertensb@defrltot002 ~]$ sudo
>>>>> /usr/sbin/matchpathcon -V /etc/sssd/sssd.conf /etc/sssd/sssd.conf
>>>>> verified.
>>>>>
>>>>> Repeating my test of matchpathcon: [mertensb@defrltot002 ~]$ touch
>>>>> /tmp/proftpd [mertensb@defrltot002 ~]$ sudo mv /tmp/proftpd
>>>>> /etc/cron.monthly/proftpd [mertensb@defrltot002 ~]$ sudo ls -lZ
>>>>> /etc/cron.monthly/proftpd -rw-r--r--. mertensb ISOP
>>>>> unconfined_u:object_r:user_ tmp_t:s0 /etc/cron.monthly/proftpd
>>>>> [mertensb@defrltot002 ~]$ sudo /usr/sbin/matchpathcon
>>>>> /etc/cron.monthly/proftpd /etc/cron.monthly/proftpd
>>>>> system_u:object_r:ftpd_exec_t:s0 [mertensb@defrltot002 ~]$ sudo
>>>>> /usr/sbin/matchpathcon -V /etc/cron.monthly/proftpd
>>>>> /etc/cron.monthly/proftpd has context
>>>>> unconfined_u:object_r:user_tmp_t:s0, should be
>>>>> system_u:object_r:ftpd_exec_t:s0
>>>>>
>>>>> Both have the same sssd SELinux policy loaded: RHEL5:
>>>>> [mertensb@testadintegration01 ~]$ sudo /usr/sbin/semodule -l|grep
>>>>> sssd sssd 1.0.2 RHEL6: [mertensb@defrltot002 ~]$ sudo
>>>>> /usr/sbin/semodule -l|grep sssd sssd 1.0.2
>>>>>
>>>>> Digging further I found out that if only the user context is
>>>>> different matchpathcon returns OK. See
>>>>> http://manpages.ubuntu.com/manpages/karmic/man3/matchpathcon.3.html
>>>>>
>>>>> I also found a post on this list indicating that restorecon has a
>>>>> forece option to make it set the user context which it doesn't do by
>>>>> default:
>>>>> http://fedora.12.x6.nabble.com/restorecon-isn-t-restoring-what-matchpathc...
>>>>>
>>>>>
>>>>>
> So why isn't the user context set/reset by default? After all it clearly
>>>>> leaves the system in a broken state.
>>>>>
>>>>> And why doesn't matchpathcon have a similar force option to make it
>>>>> check the entire context?
>>>>>
>>>>> Thanks in advance.
>>>>>
>>>>> Bram Mertens -- selinux mailing list selinux(a)lists.fedoraproject.org
>>>>> https://admin.fedoraproject.org/mailman/listinfo/selinux
>>>>>
>>
>> Well the user component is ignored on almost every SELinux System and all
>> that are shipped with policy from Red Hat.
>>
>> The first couple of paragraphs of
>>
>> http://danwalsh.livejournal.com/63586.html
>>
>> explain this.
>>
>> restorecon main goal is to fix the "type" portion of the SELinux label and
>> not to touch the User component or the MLS field unless you specify -F.
>>
>>
>>
>>
>>
>>
>>
>> So does that mean that rhncfg-client is doing something wrong when it fails
>> on this? Should I then raise this as an issue for rhncfg-client?
>>
>> Regards
>>
>> Bram -- selinux mailing list selinux(a)lists.fedoraproject.org
>> https://admin.fedoraproject.org/mailman/listinfo/selinux
>>
>
> Yes it should just use restorecon and not try to be smart with matchpathcon,
> If it wants to force the context then use the -f option.
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.14 (GNU/Linux)
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iEYEARECAAYFAlH5fyMACgkQrlYvE4MpobO8UwCg4naOAvn8svIWNPPpCrFeD/tr
> E6AAnR7NQbCLOnNSB7hbbR7mhpQwQ48v
> =YHCy
> -----END PGP SIGNATURE-----
One final update in case anyone runs into this as well.
The problem was not caused by the incorrect user label but because the
service mcstrans wasn't running.
It appears that this service is responsible for handling these user
label corrections.
So the solution to the above stack trace is to start the mcstrans service.
When the mcstrans service is running the user context is automatically
corrected.
HTH
Bram
10 years, 2 months
fail2ban + ipset problem?
by Charles Bradshaw
I'm running Fedora 17, kernel 3.9.10-100.fc17.i686.PAE
I am installing and configuring ipset as an addition to fail2ban, which
I have been running successfully for some time.
I expected some complaints from selinux so I have set permissive mode
and the first run of fail2ban produces this audit.log when ipset tries
to run to insert a ban:
type=AVC msg=audit(1379280989.345:21513): avc: denied { create } for
pid=4270 comm="ipset" scontext=system_u:system_r:fail2ban_t:s0
tcontext=system_u:system_r:fail2ban_t:s0 tclass=netlink_socket
I create fail2ban.te:
# cat /var/log/audit/audit.log | audit2allow -m fail2ban > fail2ban.te
Which looks like this:
module fail2ban 1.0;
require {
type fail2ban_t;
class netlink_socket { bind create getattr };
}
#============= fail2ban_t ==============
allow fail2ban_t self:netlink_socket { bind create getattr };
Foe the record I have done these:
# checkmodule -M -m -o fail2ban.mod fail2ban.te
checkmodule: loading policy configuration from fail2ban.te
checkmodule: policy configuration loaded
checkmodule: writing binary representation (version 15) to fail2ban.mod
# semodule_package -o fail2ban.pp -m fail2ban.mod
But the install FAILS:
# semodule --verbose -i fail2ban.pp
Attempting to install module 'fail2ban.pp':
Ok: return value of 0.
Committing changes:
libsepol.print_missing_requirements: fail2ban-client's global
requirements were not met: type/attribute fail2ban_var_run_t
libsemanage.semanage_link_sandbox: Link packages failed
semodule: FaiI'm running Fedora 17, kernel 3.9.10-100.fc17.i686.PAE
I am installing and configuring ipset as an addition to fail2ban, which
I have been running successfuly for some time.
I expected some complaints from selinux so I have set permissive mode
and the first run of fail2ban produces this audit.log:
type=AVC msg=audit(1379280989.345:21513): avc: denied { create } for
pid=4270 comm="ipset" scontext=system_u:system_r:fail2ban_t:s0
tcontext=system_u:system_r:fail2ban_t:s0 tclass=netlink_socket
I create fail2ban.te:
# cat /var/log/audit/audit.log | audit2allow -m local > fail2ban.te
Which looks like this:
module fail2ban 1.0;
require {
type fail2ban_t;
class netlink_socket { bind create getattr };
}
#============= fail2ban_t ==============
allow fail2ban_t self:netlink_socket { bind create getattr };
Foe the record I have done these:
# checkmodule -M -m -o fail2ban.mod fail2ban.te
checkmodule: loading policy configuration from fail2ban.te
checkmodule: policy configuration loaded
checkmodule: writing binary representation (version 15) to fail2ban.mod
# semodule_package -o fail2ban.pp -m fail2ban.mod
But this FAILS:
# semodule --verbose -i fail2ban.pp
Attempting to install module 'fail2ban.pp':
Ok: return value of 0.
Committing changes:
libsepol.print_missing_requirements: fail2ban-client's global
requirements were not met: type/attribute fail2ban_var_run_t
libsemanage.semanage_link_sandbox: Link packages failed
semodule: Failed!
However:
# seinfo --type=fail2ban_var_run_t
fail2ban_var_run_t
I see no requirement for fail2ban_var_run_t in fail2ban.te!
I have previously compiled and installed this:
module fail2ban-client 1.0;
require {
type httpd_log_t;
type fail2ban_var_run_t;
type fail2ban_client_t;
class dir { read write search };
}
#============= fail2ban_client_t ==============
allow fail2ban_client_t fail2ban_var_run_t:dir write;
allow fail2ban_client_t httpd_log_t:dir read;
allow fail2ban_client_t httpd_log_t:dir search;
Which compiles and installs without a problem!
What am I missing?
TIA Charles Bradshawled!
However seinfo says:
# seinfo --type=fail2ban_var_run_t
fail2ban_var_run_t
I don't see any requirement for fail2ban_var_run_t in the above!
I have previously installed fail2ban-client which allows fail2ban to
monitor /var/log/httpd/access_log and write to its own log:
module fail2ban-client 1.0;
require {
type httpd_log_t;
type fail2ban_var_run_t;
type fail2ban_client_t;
class dir { read write search };
}
#============= fail2ban_client_t ==============
allow fail2ban_client_t fail2ban_var_run_t:dir write;
allow fail2ban_client_t httpd_log_t:dir read;
allow fail2ban_client_t httpd_log_t:dir search;
Which compiles and installs without a problem!
NB fail2ban-client.te contains type fail2ban_var_run_t
What am I missing?
TIA Charles Bradshaw
10 years, 2 months
Re: Executables in a home directory
by Dominick Grift
On Mon, 2013-08-05 at 12:47 -0400, m.roth(a)5-cent.us wrote:
> Dominick Grift wrote:
> > On Mon, 2013-08-05 at 11:16 -0400, m.roth(a)5-cent.us wrote:
> >> We've got a service (motion) that has an NFS-mounted home directory. In
> >> that directory is ./bin, and some executables. Is there a boolean to
> >> allow
> >> that to be executed, or do I have to add a policy to allow that on every
> >> system that is running the service?
> >>
> >> Btw, the system it just showed up on is a newly updated FC19.
> >>
> >> mark
> >
> > Show us avc denials please
>
> First, here's getsebool -a | grep -i nfs
>
> cobbler_use_nfs --> off
> ftpd_use_nfs --> off
> git_cgi_use_nfs --> off
> git_system_use_nfs --> off
> httpd_use_nfs --> on
> ksmtuned_use_nfs --> off
> mpd_use_nfs --> off
> nfs_export_all_ro --> on
> nfs_export_all_rw --> on
> nfsd_anon_write --> off
> polipo_use_nfs --> off
> samba_share_nfs --> off
> sanlock_use_nfs --> off
> sge_use_nfs --> off
> use_nfs_home_dirs --> on
> virt_use_nfs --> off
> xen_use_nfs --> off
>
> I've got several - here's three:
>
> type=AVC msg=audit(1375711978.360:34383): avc: denied { read } for
> pid=32095 comm="mplayer" name="2013-08-05" dev="0:38" ino=29229135
> scontext=system_u:system_r:zoneminder_t:s0
> tcontext=system_u:object_r:nfs_t:s0 tclass=dir
>
Where exactly is this directory "2013-08-05"?
You might be able to find it with the find command: find / -inum
29229135
But yes you would need to add rules to conditionally allow this in
theory (create a boolean zoneminder_use_nfs)
> This one is even more fun: it doesn't think bash should be allowed to
> execute mplayer (if I've got the sealert and the audit.log entry matched
> up....)
>
> type=AVC msg=audit(1375711977.280:34380): avc: denied { execute } for
> pid=32095 comm="mplayer" path="/usr/bin/mplayer" dev="sda3" ino=793612
> scontext=system_u:system_r:zoneminder_t:s0
> tcontext=system_u:object_r:mplayer_exec_t:s0 tclass=file
>
That one looks strange because it seems that mplayer executes itself. In
theory you can use audit2allow to allow this.
> Is this what you needed?
>
> mark
>
>
10 years, 3 months
update breaks sandbox functionality
by fedorauser
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Hi,
FYI:
yesterday a few new updates came in via updates-testing:
policycoreutils-2.1.14-46.5.fc19.x86_64
policycoreutils-python-2.1.14-46.5.fc19.x86_64
policycoreutils-sandbox-2.1.14-46.5.fc19.x86_64
Since I installed them sandbox functionality
(e.g. "sandbox -X -t sandbox_web_t firefox") stopped working (no
window would show up).
Downgrading these packages results in a working setup again:
yum downgrade policycoreutils policycoreutils-python
policycoreutils-sandbox
I didn't look into any audit logs but I might be able to do that with
my testing VM later.
-----BEGIN PGP SIGNATURE-----
iQEcBAEBCgAGBQJSKbloAAoJEHgmGhf8XKddeeAH/iFkixLcN4yP1ZR5UAD6wHC3
YOphILveBoStMRjTQEPUZhdtXNsWbjggKeNd0AGoje8a0Bx3clSAfjin2qGxtNrW
FHUeQE3/ZmOgI7GPil68OaJvX8caM/KwIH+vw7CVkAZ4QnMgIq8B+U9FlJaOfdY2
0T8NbOesVTInCBXkSyNwHMmTPvp1IIUzll6gMZEPFb5fwKGW+UAamnV2xPI1T82a
qxFWDdeu21gk4IG1Y5cLspWERRr6O8iDeZcbiNPift6FffnPVlQ8YFM+cFXZ48OG
lbLmX1hyR32lLa4wrm5TQe8tkFhR7T4Adr9y9mrCxMJ7FqUH3mqX/FtKt5HnEkI=
=3WNo
-----END PGP SIGNATURE-----
-------------------------------------------------
VFEmail.net - http://www.vfemail.net
$14.95 ONETIME Lifetime accounts with Privacy Features!
15GB disk! No bandwidth quotas!
Commercial and Bulk Mail Options!
10 years, 3 months
SELinux constrain policy for escalated root user
by Anamitra Dutta Majumdar
We need to constrain a tomcat escalated root user from executing "useradd" and "semanage" commands on RHEL6.
Can we add a SELinux constraint policy to achieve the same?
A tomcat escalated root user (I.e when a "tomcat" user escalates to the "root" user on the system)
has the following security context
uid=0(root) gid=0(root)
groups=0(root),1(bin),2(daemon),3(sys),4(adm),6(disk),10(wheel)
context=system_u:system_r:tomcatd_t:SystemLow-SystemHigh
The logic of this constraint should be be as follows..
If id="root" and source type="tomcatd_t"
Then disallow domain transition to both "useradd_exec_t" as well as "semanage_exec_t"
1. Is this something doable through an SELinux constrain policy.
2. If so what should be the syntax of the policy.
10 years, 3 months
