weird dyntransition issue
 

On Sun, 2012-03-25 at 14:02 +0100, Mr Dash Four wrote:
> Since upgrading to the latest openssh (server) - v5.8p2-25 - and using
> kernel 3.2 I started getting the following avc when trying to connect
> via sftp and attempting to delete/change various files (please note that
> sftpd_full_access is on!):
>
> type=AVC msg=audit(1332653118.024:179): avc: denied { dyntransition }
> for pid=1989 comm="sshd"
> scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023
> tcontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
> tclass=process
> type=SYSCALL msg=audit(1332653118.024:179): arch=40000003 syscall=4
> success=no exit=-13 a0=3 a1=e11a48 a2=36 a3=e11a48 items=0 ppid=1986
> pid=1989 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0
> tty=(none) ses=3 comm="sshd" exe="/usr/sbin/sshd"
> subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 key=(null)

What does audit2why say?

Might be a constraint issue?

Some shots in the dark:

# get past dyntransition kiddy lock
domain_dyntrans_type(sshd_t)

# get past subject identity change kiddy lock
domain_subj_id_change_exemption(sshd_t)

# get past role change kiddy lock
domain_role_change_exemption(sshd_t)

> I did not get the above avc with the previous version of openssh I was
> using (v5.6) and I suspect it is something to do with the unprivileged
> user transition feature, which has been implemented in this version, but
> I can't be 100% sure.
>
> I have tried to counter the above avc with including
> "dyntrans_pattern(sshd_t, unconfined_t)", then
> "unconfined_domtrans(sshd_t)" and finally a raw "allow sshd_t
> unconfined_t:process { dyntransition };" but to no avail - I am still
> getting the above avc! What am I doing wrong and is there a way to get
> this sorted? Many thanks!
> --
> selinux mailing list
> selinux@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/selinux


--
selinux mailing list
selinux@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/selinux

weird dyntransition issue
 

What does audit2why say?


Well, not what I expected :- :

-bash-4.1# audit2why < /var/log/audit/audit.log
Traceback (most recent call last):
File "/usr/bin/audit2allow", line 24, in <module>
import sepolgen.policygen as policygen
File "/usr/lib/python2.6/site-packages/sepolgen/policygen.py", line
33, in <module>

from setools import *
ImportError: No module named setools

So, I guess I have to transfer my audit.log on a machine which does have
setools (python) installed (the one I am getting this on is my dmz
server, so it is pretty constrained).



Some shots in the dark:

# get past dyntransition kiddy lock
domain_dyntrans_type(sshd_t)

# get past subject identity change kiddy lock
domain_subj_id_change_exemption(sshd_t)

# get past role change kiddy lock
domain_role_change_exemption(sshd_t)

I'll try these, thanks Dominick! I'll introduce these one by one as
tunables and see what works.


Could it be that the new version of openssh introduced these new hooks,
which were not present in older versions? To me this whole issue is
caused entirely by openssh.


--
selinux mailing list
selinux@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/selinux

weird dyntransition issue
 

On Sun, 2012-03-25 at 18:11 +0100, Mr Dash Four wrote:
> > What does audit2why say?
> >
> Well, not what I expected :- :
>
> -bash-4.1# audit2why < /var/log/audit/audit.log
> Traceback (most recent call last):
> File "/usr/bin/audit2allow", line 24, in <module>
> import sepolgen.policygen as policygen
> File "/usr/lib/python2.6/site-packages/sepolgen/policygen.py", line
> 33, in <module>
> from setools import *
> ImportError: No module named setools

ouch

> So, I guess I have to transfer my audit.log on a machine which does have
> setools (python) installed (the one I am getting this on is my dmz
> server, so it is pretty constrained).
>
> > Some shots in the dark:
> >
> > # get past dyntransition kiddy lock
> > domain_dyntrans_type(sshd_t)
> >
> > # get past subject identity change kiddy lock
> > domain_subj_id_change_exemption(sshd_t)
> >
> > # get past role change kiddy lock
> > domain_role_change_exemption(sshd_t)
> >
> I'll try these, thanks Dominick! I'll introduce these one by one as
> tunables and see what works.
>
> Could it be that the new version of openssh introduced these new hooks,
> which were not present in older versions? To me this whole issue is
> caused entirely by openssh.
>

not likely, i am not sure though

--
selinux mailing list
selinux@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/selinux

weird dyntransition issue
 

> Some shots in the dark:
>
> # get past dyntransition kiddy lock
> domain_dyntrans_type(sshd_t)
>
> # get past subject identity change kiddy lock
> domain_subj_id_change_exemption(sshd_t)
>
> # get past role change kiddy lock
> domain_role_change_exemption(sshd_t)
Nada on all counts!

When I try to compile it as part of my (modified) policy I am ending up with a syntax error like:

ERROR 'syntax error' at token 'typeattribute' on line 8921:
#line 283
typeattribute sshd_t set_curr_context;


I'll submit a bug with Fedora - I've had enough of this!
--
selinux mailing list
selinux@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/selinux

weird dyntransition issue
 

On Sun, 2012-03-25 at 18:11 +0100, Mr Dash Four wrote:

> I'll try these, thanks Dominick! I'll introduce these one by one as
> tunables and see what works.

Did you try it without tunable policy?



--
selinux mailing list
selinux@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/selinux

weird dyntransition issue
 

On 03/25/2012 11:21 PM, Mr Dash Four wrote:

Some shots in the dark:

# get past dyntransition kiddy lock
domain_dyntrans_type(sshd_t)

# get past subject identity change kiddy lock
domain_subj_id_change_exemption(sshd_t)

# get past role change kiddy lock
domain_role_change_exemption(sshd_t)

Nada on all counts!

When I try to compile it as part of my (modified) policy I am ending up with a syntax error like:

ERROR 'syntax error' at token 'typeattribute' on line 8921:
#line 283
typeattribute sshd_t set_curr_context;


I'll submit a bug with Fedora - I've had enough of this!
--
selinux mailing list
selinux@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/selinux

What OS?

$ rpm -q selinux-policy
--
selinux mailing list
selinux@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/selinux

weird dyntransition issue
 

Did you try it without tunable policy?


No, I didn't. Does it matter?
--
selinux mailing list
selinux@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/selinux

weird dyntransition issue
 

What OS?

$ rpm -q selinux-policy
selinux-policy-3.9.16-48.fc15.noarch, but as I already mentioned, this
is (heavily) modified policy. See Dominick's suggestions at the top of
this thread on what has been modified.


If I implement Dominick's suggestions as a separate module, which is
*not* part of the policy I don't get these syntax errors and I have my
mypol.pp file. If I try to do that as part of the policy-building
process, then it fails with the syntax error I already mentioned. I
can't include this separate module (mypol.pp), because I am building
LiveCD image and the root system (/) is read-only, so as soon as I
insert/install mypol.pp with semodule -i, this will be gone the next
time I reboot, so I have to incorporate these changes (provided that is
what I have to do!) as part of the policy (selinux-targeted), not as a
separate module.


All this is beside the point though. SSHD (5.8 is the version I tried
before I backtracked to the previous one I used - 5.5p1) has now some
new privilege-separation code and it seems to be causing me all these
errors. I did a little investigation yesterday before I gave up and if I
include "UsePrivilegeSeparation no" in sshd_config, then I do not get
the dyntransition avc, but I do get all the other ones (like { read }, {
unlink } on file/directory etc) which are associated with a domain
(sshd_t), which has no permission to access those files/directories -
that, to me, indicates that this "privilege separation" issue is not
completely gone even if I set "UsePrivilegeSeparation no".


When I revert back to 5.5p1 everything is hunky-dory and I have no such
issues, provided I switch sftpd_full_access to "on", otherwise I get the
same avc as above.

--
selinux mailing list
selinux@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/selinux