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
On Sun, 2013-05-19 at 14:15 +0300, Thorsten Scherf wrote:
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?
i think this is a mcs constraint issue:
cat > mytest.te <<EOF policy_module(mytest, 1.0.0) gen_require(` type local_login_t; ') mcs_process_set_categories(local_login_t) EOF
make -f /usr/share/selinux/devel/Makefile mytest.pp sudo semodule -i mytest.pp
Cheers, Thorsten
-- selinux mailing list selinux@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/selinux
On [Sun, 19.05.2013 17:15], Dominick Grift wrote:
On Sun, 2013-05-19 at 14:15 +0300, Thorsten Scherf wrote:
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?
i think this is a mcs constraint issue:
cat > mytest.te <<EOF policy_module(mytest, 1.0.0) gen_require(` type local_login_t; ') mcs_process_set_categories(local_login_t) EOF
make -f /usr/share/selinux/devel/Makefile mytest.pp sudo semodule -i mytest.pp
This indeed fixed it. Is this something that should go into the default policy? Digging through the mcs_process_set_categories interface, all it does, is to set the mcssetcats attribute on local_login_t.
On Mon, 2013-05-20 at 09:28 +0300, Thorsten Scherf wrote:
On [Sun, 19.05.2013 17:15], Dominick Grift wrote:
On Sun, 2013-05-19 at 14:15 +0300, Thorsten Scherf wrote:
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?
i think this is a mcs constraint issue:
cat > mytest.te <<EOF policy_module(mytest, 1.0.0) gen_require(` type local_login_t; ') mcs_process_set_categories(local_login_t) EOF
make -f /usr/share/selinux/devel/Makefile mytest.pp sudo semodule -i mytest.pp
This indeed fixed it. Is this something that should go into the default policy? Digging through the mcs_process_set_categories interface, all it does, is to set the mcssetcats attribute on local_login_t.
This issue is probably related to your new daemon, which currently in not confined. It probably runs the login program, but because its not confined, it run the login program with no categories.
In fedora the login program usually runs with access to all categories. It inherits acces to all categories from its parent process (whichever that is in recent fedora)
If the login program has access to all categories then it can use them to set categories on login user domains, but in your case it doesnt have access to the categories it wants to set on unconfined_u login in.
so allowing local_login_t to set categories is a workaround in this case
But the real fix is probably to confine that iucv daemon properly. if thats done then my hack isnt needed anymore
On Mon, 2013-05-20 at 09:41 +0200, Dominick Grift wrote:
On Mon, 2013-05-20 at 09:28 +0300, Thorsten Scherf wrote:
On [Sun, 19.05.2013 17:15], Dominick Grift wrote:
On Sun, 2013-05-19 at 14:15 +0300, Thorsten Scherf wrote:
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
I can help you write policy for iucv. If you want help, then please come see me (grift) on #fedora-selinux at irc.freenode.org (internet relay chat)
On [Mon, 20.05.2013 13:17], Dominick Grift wrote:
On Mon, 2013-05-20 at 09:41 +0200, Dominick Grift wrote:
On Mon, 2013-05-20 at 09:28 +0300, Thorsten Scherf wrote:
On [Sun, 19.05.2013 17:15], Dominick Grift wrote:
On Sun, 2013-05-19 at 14:15 +0300, Thorsten Scherf wrote:
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
I can help you write policy for iucv. If you want help, then please come see me (grift) on #fedora-selinux at irc.freenode.org (internet relay chat)
Thanks Dominik, but I think I can manage it. Will let you know if I need further help.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 05/20/2013 08:39 AM, Thorsten Scherf wrote:
On [Mon, 20.05.2013 13:17], Dominick Grift wrote:
On Mon, 2013-05-20 at 09:41 +0200, Dominick Grift wrote:
On Mon, 2013-05-20 at 09:28 +0300, Thorsten Scherf wrote:
On [Sun, 19.05.2013 17:15], Dominick Grift wrote:
On Sun, 2013-05-19 at 14:15 +0300, Thorsten Scherf wrote:
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
I can help you write policy for iucv. If you want help, then please come see me (grift) on #fedora-selinux at irc.freenode.org (internet relay chat)
Thanks Dominik, but I think I can manage it. Will let you know if I need further help.
-- selinux mailing list selinux@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/selinux
Yes running login ranged would be better then giving it overrides, because theoretically, someone might want to run login program with less categories.
In the MLS world you might want to setup local login to only be able to reach Secret level for example.
We are seeing this on a RHEL5 based release of our product.
The particular rule that is causing the issue is this .
allow pwrecoveryd_t etc_t:file create;
pwrecoveryd is a custom type and all the necessary policies have been loaded. However when we specifically add the above allow rule and load the policies on the target box. We keep on getting this exact same denial. This is the only denial that shows up
Any pointers to the issue would be greatly appreciated.
Thanks, Anamitra
On Mon, 2013-05-20 at 19:25 +0000, Anamitra Dutta Majumdar (anmajumd) wrote:
We are seeing this on a RHEL5 based release of our product.
The particular rule that is causing the issue is this .
allow pwrecoveryd_t etc_t:file create;
Kind of hard to speculate. Can you provide more info like for example:
1. output of : seinfo -xtpwrecoveryd_t 2. the actual avc denial 3. what does audit2why say if you feed it that avc denial?
pwrecoveryd is a custom type and all the necessary policies have been loaded. However when we specifically add the above allow rule and load the policies on the target box. We keep on getting this exact same denial. This is the only denial that shows up
Any pointers to the issue would be greatly appreciated.
Thanks, Anamitra
-- selinux mailing list selinux@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/selinux
Hi Dominick.
1. We do not have the seinfo utility available in our box so could not run it
2. The AVC denial is type=AVC msg=audit(1369081665.408:8113): avc: denied { create } for pid=18379 comm="usermod" name="passwd+" scontext=specialuser_u:system_r:pwrecoveryd_t:s0 tcontext=system_u:object_r:etc_t:s0 tclass=file
3. audit2why shows this type=AVC msg=audit(1369081665.408:8113): avc: denied { create } for pid=18379 comm="usermod" name="passwd+" scontext=specialuser_u:system_r:pwrecoveryd_t:s0 tcontext=system_u:object_r:etc_t:s0 tclass=file Was caused by: Constraint violation. Check policy/constraints. Typically, you just need to add a type attribute to the domain to satisfy the constraint.
Thanks, Anamitra
On 5/20/13 12:30 PM, "Dominick Grift" dominick.grift@gmail.com wrote:
On Mon, 2013-05-20 at 19:25 +0000, Anamitra Dutta Majumdar (anmajumd) wrote:
We are seeing this on a RHEL5 based release of our product.
The particular rule that is causing the issue is this .
allow pwrecoveryd_t etc_t:file create;
Kind of hard to speculate. Can you provide more info like for example:
- output of : seinfo -xtpwrecoveryd_t
- the actual avc denial
- what does audit2why say if you feed it that avc denial?
pwrecoveryd is a custom type and all the necessary policies have been loaded. However when we specifically add the above allow rule and load the policies on the target box. We keep on getting this exact same denial. This is the only denial that shows up
Any pointers to the issue would be greatly appreciated.
Thanks, Anamitra
-- selinux mailing list selinux@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/selinux
On Mon, 2013-05-20 at 20:44 +0000, Anamitra Dutta Majumdar (anmajumd) wrote:
Hi Dominick.
- We do not have the seinfo utility available in our box so could not run
it
Well then its hard for me to speculate as to which attribute you need to assign to your pwrecoveryd_t type
you might start with: domain_type(pwrecoveryd_t)
e.g. make it a domain type
- The AVC denial is
type=AVC msg=audit(1369081665.408:8113): avc: denied { create } for pid=18379 comm="usermod" name="passwd+" scontext=specialuser_u:system_r:pwrecoveryd_t:s0 tcontext=system_u:object_r:etc_t:s0 tclass=file
- audit2why shows this
type=AVC msg=audit(1369081665.408:8113): avc: denied { create } for pid=18379 comm="usermod" name="passwd+" scontext=specialuser_u:system_r:pwrecoveryd_t:s0 tcontext=system_u:object_r:etc_t:s0 tclass=file Was caused by: Constraint violation. Check policy/constraints. Typically, you just need to add a type attribute to the domain to satisfy the constraint.
So this tells you that its a policy constraint issue. A type enforcement rule wont help you here. You need to assign the proper type attributes to the pwrecoveryd_t type most likely
probably "domain" type attribute
Thanks, Anamitra
On 5/20/13 12:30 PM, "Dominick Grift" dominick.grift@gmail.com wrote:
On Mon, 2013-05-20 at 19:25 +0000, Anamitra Dutta Majumdar (anmajumd) wrote:
We are seeing this on a RHEL5 based release of our product.
The particular rule that is causing the issue is this .
allow pwrecoveryd_t etc_t:file create;
Kind of hard to speculate. Can you provide more info like for example:
- output of : seinfo -xtpwrecoveryd_t
- the actual avc denial
- what does audit2why say if you feed it that avc denial?
pwrecoveryd is a custom type and all the necessary policies have been loaded. However when we specifically add the above allow rule and load the policies on the target box. We keep on getting this exact same denial. This is the only denial that shows up
Any pointers to the issue would be greatly appreciated.
Thanks, Anamitra
-- selinux mailing list selinux@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/selinux
We managed to install setools and we see the following as the output of seinfo
[root@cap-715-pub ~]# seinfo -xtpwrecoveryd_t Rule loading disabled pwrecoveryd_t @ttr0191 @ttr1241 @ttr2387 @ttr2703
Thanks, Anamitra
On 5/20/13 2:51 PM, "Dominick Grift" dominick.grift@gmail.com wrote:
On Mon, 2013-05-20 at 20:44 +0000, Anamitra Dutta Majumdar (anmajumd) wrote:
Hi Dominick.
- We do not have the seinfo utility available in our box so could not
run it
Well then its hard for me to speculate as to which attribute you need to assign to your pwrecoveryd_t type
you might start with: domain_type(pwrecoveryd_t)
e.g. make it a domain type
- The AVC denial is
type=AVC msg=audit(1369081665.408:8113): avc: denied { create } for pid=18379 comm="usermod" name="passwd+" scontext=specialuser_u:system_r:pwrecoveryd_t:s0 tcontext=system_u:object_r:etc_t:s0 tclass=file
- audit2why shows this
type=AVC msg=audit(1369081665.408:8113): avc: denied { create } for pid=18379 comm="usermod" name="passwd+" scontext=specialuser_u:system_r:pwrecoveryd_t:s0 tcontext=system_u:object_r:etc_t:s0 tclass=file Was caused by: Constraint violation. Check policy/constraints. Typically, you just need to add a type attribute to the domain to satisfy the constraint.
So this tells you that its a policy constraint issue. A type enforcement rule wont help you here. You need to assign the proper type attributes to the pwrecoveryd_t type most likely
probably "domain" type attribute
Thanks, Anamitra
On 5/20/13 12:30 PM, "Dominick Grift" dominick.grift@gmail.com wrote:
On Mon, 2013-05-20 at 19:25 +0000, Anamitra Dutta Majumdar (anmajumd) wrote:
We are seeing this on a RHEL5 based release of our product.
The particular rule that is causing the issue is this .
allow pwrecoveryd_t etc_t:file create;
Kind of hard to speculate. Can you provide more info like for example:
- output of : seinfo -xtpwrecoveryd_t
- the actual avc denial
- what does audit2why say if you feed it that avc denial?
pwrecoveryd is a custom type and all the necessary policies have been loaded. However when we specifically add the above allow rule and load the policies on the target box. We keep on getting this exact same denial. This is the only denial
that
shows up
Any pointers to the issue would be greatly appreciated.
Thanks, Anamitra
-- selinux mailing list selinux@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/selinux
On Mon, 2013-05-20 at 23:41 +0000, Anamitra Dutta Majumdar (anmajumd) wrote:
We managed to install setools and we see the following as the output of seinfo
[root@cap-715-pub ~]# seinfo -xtpwrecoveryd_t Rule loading disabled pwrecoveryd_t @ttr0191 @ttr1241 @ttr2387 @ttr2703
Yes this selinux installation seems very old. the attributes arent translated to human readable so i cant really read it.
did you try assigning the domain type attribute to the pwrecoveryd_t type?
You could enclose your source policy module , maybe that will enable me to determine which attribute you need.
Thanks, Anamitra
On 5/20/13 2:51 PM, "Dominick Grift" dominick.grift@gmail.com wrote:
On Mon, 2013-05-20 at 20:44 +0000, Anamitra Dutta Majumdar (anmajumd) wrote:
Hi Dominick.
- We do not have the seinfo utility available in our box so could not
run it
Well then its hard for me to speculate as to which attribute you need to assign to your pwrecoveryd_t type
you might start with: domain_type(pwrecoveryd_t)
e.g. make it a domain type
- The AVC denial is
type=AVC msg=audit(1369081665.408:8113): avc: denied { create } for pid=18379 comm="usermod" name="passwd+" scontext=specialuser_u:system_r:pwrecoveryd_t:s0 tcontext=system_u:object_r:etc_t:s0 tclass=file
- audit2why shows this
type=AVC msg=audit(1369081665.408:8113): avc: denied { create } for pid=18379 comm="usermod" name="passwd+" scontext=specialuser_u:system_r:pwrecoveryd_t:s0 tcontext=system_u:object_r:etc_t:s0 tclass=file Was caused by: Constraint violation. Check policy/constraints. Typically, you just need to add a type attribute to the domain to satisfy the constraint.
So this tells you that its a policy constraint issue. A type enforcement rule wont help you here. You need to assign the proper type attributes to the pwrecoveryd_t type most likely
probably "domain" type attribute
Thanks, Anamitra
On 5/20/13 12:30 PM, "Dominick Grift" dominick.grift@gmail.com wrote:
On Mon, 2013-05-20 at 19:25 +0000, Anamitra Dutta Majumdar (anmajumd) wrote:
We are seeing this on a RHEL5 based release of our product.
The particular rule that is causing the issue is this .
allow pwrecoveryd_t etc_t:file create;
Kind of hard to speculate. Can you provide more info like for example:
- output of : seinfo -xtpwrecoveryd_t
- the actual avc denial
- what does audit2why say if you feed it that avc denial?
pwrecoveryd is a custom type and all the necessary policies have been loaded. However when we specifically add the above allow rule and load the policies on the target box. We keep on getting this exact same denial. This is the only denial
that
shows up
Any pointers to the issue would be greatly appreciated.
Thanks, Anamitra
-- selinux mailing list selinux@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/selinux
Hi Dominick,
We are already assigning the domain type attribute to pwrecoveryd_t and with that We are seeing this issue.
As for the seinfo utility we installed the latest rpm available from RHN for the RHEL5 Release train and this is the behavior we see.
Additionally the seinfo utility does not have the "--constrain" option whereas the seinfo In RHEL6 has this option which enables us to see all the constraints on the system.
Thanks, Anamitra
On 5/21/13 12:00 AM, "Dominick Grift" dominick.grift@gmail.com wrote:
On Mon, 2013-05-20 at 23:41 +0000, Anamitra Dutta Majumdar (anmajumd) wrote:
We managed to install setools and we see the following as the output of seinfo
[root@cap-715-pub ~]# seinfo -xtpwrecoveryd_t Rule loading disabled pwrecoveryd_t @ttr0191 @ttr1241 @ttr2387 @ttr2703
Yes this selinux installation seems very old. the attributes arent translated to human readable so i cant really read it.
did you try assigning the domain type attribute to the pwrecoveryd_t type?
You could enclose your source policy module , maybe that will enable me to determine which attribute you need.
Thanks, Anamitra
On 5/20/13 2:51 PM, "Dominick Grift" dominick.grift@gmail.com wrote:
On Mon, 2013-05-20 at 20:44 +0000, Anamitra Dutta Majumdar (anmajumd) wrote:
Hi Dominick.
- We do not have the seinfo utility available in our box so could
not
run it
Well then its hard for me to speculate as to which attribute you need
to
assign to your pwrecoveryd_t type
you might start with: domain_type(pwrecoveryd_t)
e.g. make it a domain type
- The AVC denial is
type=AVC msg=audit(1369081665.408:8113): avc: denied { create } for pid=18379 comm="usermod" name="passwd+" scontext=specialuser_u:system_r:pwrecoveryd_t:s0 tcontext=system_u:object_r:etc_t:s0 tclass=file
- audit2why shows this
type=AVC msg=audit(1369081665.408:8113): avc: denied { create } for pid=18379 comm="usermod" name="passwd+" scontext=specialuser_u:system_r:pwrecoveryd_t:s0 tcontext=system_u:object_r:etc_t:s0 tclass=file Was caused by: Constraint violation. Check policy/constraints. Typically, you just need to add a type attribute to
the
domain to satisfy the constraint.
So this tells you that its a policy constraint issue. A type
enforcement
rule wont help you here. You need to assign the proper type attributes to the pwrecoveryd_t type most likely
probably "domain" type attribute
Thanks, Anamitra
On 5/20/13 12:30 PM, "Dominick Grift" dominick.grift@gmail.com
wrote:
On Mon, 2013-05-20 at 19:25 +0000, Anamitra Dutta Majumdar
(anmajumd)
wrote:
We are seeing this on a RHEL5 based release of our product.
The particular rule that is causing the issue is this .
allow pwrecoveryd_t etc_t:file create;
Kind of hard to speculate. Can you provide more info like for
example:
- output of : seinfo -xtpwrecoveryd_t
- the actual avc denial
- what does audit2why say if you feed it that avc denial?
pwrecoveryd is a custom type and all the necessary policies have
been
loaded. However when we specifically add the above allow rule and load the policies on the target box. We keep on getting this exact same denial. This is the only denial
that
shows up
Any pointers to the issue would be greatly appreciated.
Thanks, Anamitra
-- selinux mailing list selinux@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/selinux
On Tue, 2013-05-21 at 15:30 +0000, Anamitra Dutta Majumdar (anmajumd) wrote:
Hi Dominick,
We are already assigning the domain type attribute to pwrecoveryd_t and with that We are seeing this issue.
As for the seinfo utility we installed the latest rpm available from RHN for the RHEL5 Release train and this is the behavior we see.
Additionally the seinfo utility does not have the "--constrain" option whereas the seinfo In RHEL6 has this option which enables us to see all the constraints on the system.
Try the solution suggested by Daniel Walsh (see his reply to this thread):
domain_obj_id_change_exemption(pwrecoveryd_t)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
- The AVC denial is type=AVC msg=audit(1369081665.408:8113): avc: denied
{ create } for pid=18379 comm="usermod" name="passwd+" scontext=specialuser_u:system_r:pwrecoveryd_t:s0 tcontext=system_u:object_r:etc_t:s0 tclass=file
The avc shows a process running as SELinux user is attempting to create a file labeled system_u:object_r:etc_t:s0. Since you are changing the SELinux user component you get an AVC. Does your app do a setfscreatecon() call?
domain_obj_id_change_exemption(pwrecoveryd_t) is probably what you need.
Hi Dan,
Thanks for the pointer . Will give this a try.
-Anamitra
On 5/21/13 6:07 AM, "Daniel J Walsh" dwalsh@redhat.com wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
- The AVC denial is type=AVC msg=audit(1369081665.408:8113): avc:
denied { create } for pid=18379 comm="usermod" name="passwd+" scontext=specialuser_u:system_r:pwrecoveryd_t:s0 tcontext=system_u:object_r:etc_t:s0 tclass=file
The avc shows a process running as SELinux user is attempting to create a file labeled system_u:object_r:etc_t:s0. Since you are changing the SELinux user component you get an AVC. Does your app do a setfscreatecon() call?
domain_obj_id_change_exemption(pwrecoveryd_t) is probably what you need. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.13 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iEYEARECAAYFAlGbcZkACgkQrlYvE4MpobMVegCfVG3yKECgQriAUxY8mxAA85cJ cP8AnisdaxW1NcIvuwMzRp65r+/KiEeV =R7ik -----END PGP SIGNATURE-----
Hi Dan,
We added the domain_obj_id_change_exemption(pwrecoveryd_t) to our src module but no luck.
And also our app does not do a setfscreatecon() call however from the syslogs we found Calls to setfscreate() by our app.
Is there a way to look at the constraints on a RHEL5 box using seinfo.
As indicated earlier in the email thread , the seinfo command on RHEL5 does not have the "--constrain" option.
Thanks, Anamitra
On 5/21/13 8:36 AM, "Anamitra Dutta Majumdar (anmajumd)" anmajumd@cisco.com wrote:
Hi Dan,
Thanks for the pointer . Will give this a try.
-Anamitra
On 5/21/13 6:07 AM, "Daniel J Walsh" dwalsh@redhat.com wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
- The AVC denial is type=AVC msg=audit(1369081665.408:8113): avc:
denied { create } for pid=18379 comm="usermod" name="passwd+" scontext=specialuser_u:system_r:pwrecoveryd_t:s0 tcontext=system_u:object_r:etc_t:s0 tclass=file
The avc shows a process running as SELinux user is attempting to create a file labeled system_u:object_r:etc_t:s0. Since you are changing the SELinux user component you get an AVC. Does your app do a setfscreatecon() call?
domain_obj_id_change_exemption(pwrecoveryd_t) is probably what you need. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.13 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iEYEARECAAYFAlGbcZkACgkQrlYvE4MpobMVegCfVG3yKECgQriAUxY8mxAA85cJ cP8AnisdaxW1NcIvuwMzRp65r+/KiEeV =R7ik -----END PGP SIGNATURE-----
-- selinux mailing list selinux@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/selinux
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 05/21/2013 02:04 PM, Anamitra Dutta Majumdar (anmajumd) wrote:
Hi Dan,
We added the domain_obj_id_change_exemption(pwrecoveryd_t) to our src module but no luck.
And also our app does not do a setfscreatecon() call however from the syslogs we found Calls to setfscreate() by our app.
Is there a way to look at the constraints on a RHEL5 box using seinfo.
As indicated earlier in the email thread , the seinfo command on RHEL5 does not have the "--constrain" option.
Thanks, Anamitra
Could you attach your current AVC messages? Are you using kerberos libraries?
Hi Dan ,
Here is the related AVC denial
type=AVC msg=audit(1369177581.853:57912): avc: denied { create } for pid=18778 comm="usermod" name="passwd+" scontext=specialuser_u:system_r:pwrecoveryd_t:s0 tcontext=system_u:object_r:etc_t:s0 tclass=file type=SYSCALL msg=audit(1369177581.853:57912): arch=40000003 syscall=5 success=yes exit=5 a0=bff19038 a1=8241 a2=1b6 a3=9df3670 items=2 ppid=18765 pid=18778 auid=503 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=tty1 ses=1624 comm="usermod" exe="/usr/sbin/usermod" subj=specialuser_u:system_r:pwrecoveryd_t:s0 key=(null) type=CWD msg=audit(1369177581.853:57912): cwd="/home/pwrecovery" type=PATH msg=audit(1369177581.853:57912): item=0 name="/etc/" inode=3103841 dev=08:01 mode=040755 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:etc_t:s0type=PATH msg=audit(1369177581.853:57912): item=1 name="/etc/passwd+" inode=3105686 dev=08:01 mode=0100000 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:etc_t:s0
And we are not using kerberos for any authentication on our system.
Thanks, Anamitra
On 5/22/13 10:04 AM, "Daniel J Walsh" dwalsh@redhat.com wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 05/21/2013 02:04 PM, Anamitra Dutta Majumdar (anmajumd) wrote:
Hi Dan,
We added the domain_obj_id_change_exemption(pwrecoveryd_t) to our src module but no luck.
And also our app does not do a setfscreatecon() call however from the syslogs we found Calls to setfscreate() by our app.
Is there a way to look at the constraints on a RHEL5 box using seinfo.
As indicated earlier in the email thread , the seinfo command on RHEL5 does not have the "--constrain" option.
Thanks, Anamitra
Could you attach your current AVC messages? Are you using kerberos libraries? -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.13 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iEYEARECAAYFAlGc+pwACgkQrlYvE4MpobN/6QCgtqqBj0lc0PJQqp7gIGUNwB+N ptkAoKu36vK2vcqUgymCVyNbQ9Va5hYh =+6sy -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 05/22/2013 03:35 PM, Anamitra Dutta Majumdar (anmajumd) wrote:
Hi Dan ,
Here is the related AVC denial
type=AVC msg=audit(1369177581.853:57912): avc: denied { create } for pid=18778 comm="usermod" name="passwd+" scontext=specialuser_u:system_r:pwrecoveryd_t:s0 tcontext=system_u:object_r:etc_t:s0 tclass=file type=SYSCALL msg=audit(1369177581.853:57912): arch=40000003 syscall=5 success=yes exit=5 a0=bff19038 a1=8241 a2=1b6 a3=9df3670 items=2 ppid=18765 pid=18778 auid=503 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=tty1 ses=1624 comm="usermod" exe="/usr/sbin/usermod" subj=specialuser_u:system_r:pwrecoveryd_t:s0 key=(null) type=CWD msg=audit(1369177581.853:57912): cwd="/home/pwrecovery" type=PATH msg=audit(1369177581.853:57912): item=0 name="/etc/" inode=3103841 dev=08:01 mode=040755 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:etc_t:s0type=PATH msg=audit(1369177581.853:57912): item=1 name="/etc/passwd+" inode=3105686 dev=08:01 mode=0100000 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:etc_t:s0
And we are not using kerberos for any authentication on our system.
Ok usermod and useradd do the setfilecon calls. One thing you might want to do is transition to useradd_t.
usermanage_domtrans_useradd(pwrecoverd_t)
User add currently has these two exceptions.
domain_obj_id_change_exemption(useradd_t) domain_system_change_exemption(useradd_t)
It looks like you might need both if you want pwrecoveryd_t to do this.
Thanks, Anamitra
On 5/22/13 10:04 AM, "Daniel J Walsh" dwalsh@redhat.com wrote:
On 05/21/2013 02:04 PM, Anamitra Dutta Majumdar (anmajumd) wrote:
Hi Dan,
We added the domain_obj_id_change_exemption(pwrecoveryd_t) to our src module but no luck.
And also our app does not do a setfscreatecon() call however from the syslogs we found Calls to setfscreate() by our app.
Is there a way to look at the constraints on a RHEL5 box using seinfo.
As indicated earlier in the email thread , the seinfo command on RHEL5 does not have the "--constrain" option.
Thanks, Anamitra
Could you attach your current AVC messages? Are you using kerberos libraries?
-- selinux mailing list selinux@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/selinux
selinux@lists.fedoraproject.org
-
Anamitra Dutta Majumdar -
Daniel J Walsh -
Dominick Grift -
Thorsten Scherf