6:15 a.m.
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:15 a.m.
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(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/selinux
1:28 a.m.
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.
2:41 a.m.
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
6:17 a.m.
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)
7:39 a.m.
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.
8:07 a.m.
-----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(a)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.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.13 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iEYEARECAAYFAlGaIC4ACgkQrlYvE4MpobMGcgCfRY5MwsY0Ke2BVlWB1J0NVUNi
UkcAn2VjX8ZtcCY+AeNC0Lp44Ga9otr7
=Z8Za
-----END PGP SIGNATURE-----
2:25 p.m.
New subject: Denial showing up even when allow rule appied
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
2:30 p.m.
New subject: Denial showing up even when allow rule appied
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(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/selinux
3:44 p.m.
New subject: Denial showing up even when allow rule appied
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(a)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:
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(a)lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/selinux
4:51 p.m.
New subject: Denial showing up even when allow rule appied
On Mon, 2013-05-20 at 20:44 +0000, Anamitra Dutta Majumdar (anmajumd)
wrote:
Hi Dominick.
1. 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
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.
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(a)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:
>
>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(a)lists.fedoraproject.org
>> https://admin.fedoraproject.org/mailman/listinfo/selinux
>
>
6:41 p.m.
New subject: Denial showing up even when allow rule appied
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(a)gmail.com> wrote:
On Mon, 2013-05-20 at 20:44 +0000, Anamitra Dutta Majumdar (anmajumd)
wrote:
> Hi Dominick.
>
> 1. 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
> 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.
>
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(a)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:
> >
> >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(a)lists.fedoraproject.org
> >> https://admin.fedoraproject.org/mailman/listinfo/selinux
> >
> >
>
2 a.m.
New subject: Denial showing up even when allow rule appied
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(a)gmail.com> wrote:
>On Mon, 2013-05-20 at 20:44 +0000, Anamitra Dutta Majumdar (anmajumd)
>wrote:
>> Hi Dominick.
>>
>> 1. 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
>
>> 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.
>>
>
>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(a)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:
>> >
>> >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(a)lists.fedoraproject.org
>> >> https://admin.fedoraproject.org/mailman/listinfo/selinux
>> >
>> >
>>
>
>
10:30 a.m.
New subject: Denial showing up even when allow rule appied
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(a)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(a)gmail.com>
wrote:
>
> >On Mon, 2013-05-20 at 20:44 +0000, Anamitra Dutta Majumdar (anmajumd)
> >wrote:
> >> Hi Dominick.
> >>
> >> 1. 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
> >
> >> 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.
> >>
> >
> >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(a)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:
> >> >
> >> >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(a)lists.fedoraproject.org
> >> >> https://admin.fedoraproject.org/mailman/listinfo/selinux
> >> >
> >> >
> >>
> >
> >
>
10:35 a.m.
New subject: Denial showing up even when allow rule appied
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)
8:07 a.m.
New subject: Denial showing up even when allow rule appied
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
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
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-----
10:36 a.m.
New subject: Denial showing up even when allow rule appied
Hi Dan,
Thanks for the pointer . Will give this a try.
-Anamitra
On 5/21/13 6:07 AM, "Daniel J Walsh" <dwalsh(a)redhat.com> wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
> 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
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-----
1:04 p.m.
New subject: Denial showing up even when allow rule appied
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(a)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(a)redhat.com> wrote:
>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>
>> 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
>
>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(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/selinux
12:04 p.m.
New subject: Denial showing up even when allow rule appied
-----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-----
2:35 p.m.
New subject: Denial showing up even when allow rule appied
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(a)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-----
7:41 a.m.
New subject: Denial showing up even when allow rule appied
-----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(a)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(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/selinux
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.13 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iEYEARECAAYFAlGeDlwACgkQrlYvE4MpobPXhACg2bzeslGGHgkaFDG1YyMaLI8q
u24An0uUlshoGjna+TmnR6m6iUSEb/Wg
=ak6P
-----END PGP SIGNATURE-----
3984
days inactive
3988
days old
selinux@lists.fedoraproject.org
20 comments
4 participants
participants (4)
-
Anamitra Dutta Majumdar -
Daniel J Walsh -
Dominick Grift -
Thorsten Scherf