Hi all
Today I updated to FC11 and gitosis stopped working (gitosis is a collection of scripts for easing multiuser access to git repositories over ssh). I can tell it's an SELinux problem, because '/sbin/setenforcing 0' clears it up.
On the server, the git repositories are managed by the 'git' user, which has the guest_u selinux type (though it also fails when given the user_u user). The home directory (/home/git) has the correct selinux context (user_home_t) as far as I can tell and I've run 'restorecon -Rvv' anyway, just to be sure. gitosis works by calling a system binary, gitosis-serve, which lives in /usr/bin/ and has the type of 'bin_t' so guest_u should be able to execute it. Even with 'setenforcing 0' no AVC denials are created though. Checking /var/log/secure shows that the key is being accepted, and it seems like the process then hangs.
Any suggestions appreciated, Regards Jon
On Tue, 2009-06-30 at 16:21 +0100, Jonathan Stott wrote:
Hi all
Today I updated to FC11 and gitosis stopped working (gitosis is a collection of scripts for easing multiuser access to git repositories over ssh). I can tell it's an SELinux problem, because '/sbin/setenforcing 0' clears it up.
On the server, the git repositories are managed by the 'git' user, which has the guest_u selinux type (though it also fails when given the user_u user). The home directory (/home/git) has the correct selinux context (user_home_t) as far as I can tell and I've run 'restorecon -Rvv' anyway, just to be sure. gitosis works by calling a system binary, gitosis-serve, which lives in /usr/bin/ and has the type of 'bin_t' so guest_u should be able to execute it. Even with 'setenforcing 0' no AVC denials are created though. Checking /var/log/secure shows that the key is being accepted, and it seems like the process then hangs.
Any suggestions appreciated, Regards Jon
Hi,
Unload any silenced denials by running: semodule -DB
try gitosis again (in permissive mode)
After that see /var/log/audit/audit.log and attach the applicable part so that we can have a look.
After testing put it back into enforcing mode and reload the silenced denials with semodule -B
We need to have a look at avc denials.
-- fedora-selinux-list mailing list fedora-selinux-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-selinux-list
On 06/30/2009 05:21 PM, Jonathan Stott wrote:
Hi all
Today I updated to FC11 and gitosis stopped working (gitosis is a collection of scripts for easing multiuser access to git repositories over ssh). I can tell it's an SELinux problem, because '/sbin/setenforcing 0' clears it up.
On the server, the git repositories are managed by the 'git' user, which has the guest_u selinux type (though it also fails when given the user_u user). The home directory (/home/git) has the correct selinux context (user_home_t) as far as I can tell and I've run 'restorecon -Rvv' anyway, just to be sure. gitosis works by calling a system binary, gitosis-serve, which lives in /usr/bin/ and has the type of 'bin_t'
What is your verison of selinux-policy?
# rpm -q selinux-policy selinux-policy-targeted
gitosis-serve should have the following context:
# ls -Z /usr/bin/gitosis-serve -rwxr-xr-x. root root system_u:object_r:gitosis_exec_t:s0 /usr/bin/gitosis-serve
so guest_u should be able to execute it. Even with 'setenforcing 0' no AVC denials are created though. Checking /var/log/secure shows that the key is being accepted, and it seems like the process then hangs.
Any suggestions appreciated, Regards Jon
-- fedora-selinux-list mailing list fedora-selinux-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-selinux-list
Hi
# rpm -q selinux-policy selinux-policy-targeted selinux-policy-3.6.12-62.fc11.noarch selinux-policy-targeted-3.6.12-62.fc11.noarch
(previously it was 3.6.12-53)
And gitosis-serve is labelled gitosis_exec_t
Even after upgrading the selinux policy versions, it still seems to hang in the same manner though.
Regards, Jon
On 07/04/2009 07:41 AM, Jonathan Stott wrote:
Hi
# rpm -q selinux-policy selinux-policy-targeted selinux-policy-3.6.12-62.fc11.noarch selinux-policy-targeted-3.6.12-62.fc11.noarch
(previously it was 3.6.12-53)
And gitosis-serve is labelled gitosis_exec_t
Even after upgrading the selinux policy versions, it still seems to hang in the same manner though.
Regards, Jon
-- fedora-selinux-list mailing list fedora-selinux-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-selinux-list
Are you seeing any avc messages in /var/log/audit/audit.log?
ps -eZ | grep gitosis
Does this show apps running under the correct domain?
On Mon, 06 Jul 2009 08:12:26 -0400 Daniel J Walsh dwalsh@redhat.com wrote:
On 07/04/2009 07:41 AM, Jonathan Stott wrote:
Hi
# rpm -q selinux-policy selinux-policy-targeted selinux-policy-3.6.12-62.fc11.noarch selinux-policy-targeted-3.6.12-62.fc11.noarch
(previously it was 3.6.12-53)
And gitosis-serve is labelled gitosis_exec_t
Even after upgrading the selinux policy versions, it still seems to hang in the same manner though.
Regards, Jon
-- fedora-selinux-list mailing list fedora-selinux-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-selinux-list
Are you seeing any avc messages in /var/log/audit/audit.log?
ps -eZ | grep gitosis
Does this show apps running under the correct domain?
It's hard to tell whether it's running under the correct context (gitosis-serve seems to very quickly shell out to whatever git command is called and I'm not sure how to trigger ps at the correct time). However it definitely has the correct context on the executable (which is the only copy of gitosis-serve on the system), and I've relabeled the file system just to be sure.
However, I still seem to get the same AVC denial:
----------------------------------------------------------------------------- Summary:
SELinux is preventing bash (guest_t) "write" sshd_t.
Detailed Description:
SELinux denied access requested by bash. It is not expected that this access is required by bash and this access may signal an intrusion attempt. It is also possible that the specific version or configuration of the application is causing it to require additional access.
Allowing Access:
You can generate a local policy module to allow this access - see FAQ (http://fedora.redhat.com/docs/selinux-faq-fc5/#id2961385) Or you can disable SELinux protection altogether. Disabling SELinux protection is not recommended. Please file a bug report (http://bugzilla.redhat.com/bugzilla/enter_bug.cgi) against this package.
Additional Information:
Source Context guest_u:guest_r:guest_t:s0 Target Context system_u:system_r:sshd_t:s0-s0:c0.c1023 Target Objects pipe [ fifo_file ] Source bash Source Path /bin/bash Port <Unknown> Host hzhangpg02.ph.man.ac.uk Source RPM Packages bash-4.0-6.fc11 Target RPM Packages Policy RPM selinux-policy-3.6.12-62.fc11 Selinux Enabled True Policy Type targeted MLS Enabled True Enforcing Mode Enforcing Plugin Name catchall Host Name hzhangpg02.ph.man.ac.uk Platform Linux hzhangpg02.ph.man.ac.uk 2.6.29.5-191.fc11.x86_64 #1 SMP Tue Jun 16 23:23:21 EDT 2009 x86_64 x86_64 Alert Count 31 First Seen Tue 30 Jun 2009 16:48:17 BST Last Seen Tue 07 Jul 2009 10:51:13 BST Local ID 1cf6580e-12c8-48fb-bbb8-c06c3e55109d Line Numbers
Raw Audit Messages
node=hzhangpg02.ph.man.ac.uk type=AVC msg=audit(1246960273.947:80): avc: denied { write } for pid=3472 comm="bash" path="pipe:[51971]" dev=pipefs ino=51971 scontext=guest_u:guest_r:guest_t:s0 tcontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 tclass=fifo_file
node=hzhangpg02.ph.man.ac.uk type=AVC msg=audit(1246960273.947:80): avc: denied { write } for pid=3472 comm="bash" path="pipe:[51972]" dev=pipefs ino=51972 scontext=guest_u:guest_r:guest_t:s0 tcontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 tclass=fifo_file
node=hzhangpg02.ph.man.ac.uk type=SYSCALL msg=audit(1246960273.947:80): arch=c000003e syscall=59 success=yes exit=0 a0=7f5e932395d0 a1=7ffff16ddc90 a2=7f5e932314c0 a3=7ffff16dd940 items=0 ppid=3471 pid=3472 auid=501 uid=501 gid=501 euid=501 suid=501 fsuid=501 egid=501 sgid=501 fsgid=501 tty=(none) ses=5 comm="bash" exe="/bin/bash" subj=guest_u:guest_r:guest_t:s0 key=(null)
--------------------------------------------------------------------
Piping the raw audit messages into audit2allow and installing the module doesn't seem to remove them, though.
Regards, Jon
On 07/07/2009 05:59 AM, Jonathan Stott wrote:
On Mon, 06 Jul 2009 08:12:26 -0400 Daniel J Walshdwalsh@redhat.com wrote:
On 07/04/2009 07:41 AM, Jonathan Stott wrote:
Hi
# rpm -q selinux-policy selinux-policy-targeted selinux-policy-3.6.12-62.fc11.noarch selinux-policy-targeted-3.6.12-62.fc11.noarch
(previously it was 3.6.12-53)
And gitosis-serve is labelled gitosis_exec_t
Even after upgrading the selinux policy versions, it still seems to hang in the same manner though.
Regards, Jon
-- fedora-selinux-list mailing list fedora-selinux-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-selinux-list
Are you seeing any avc messages in /var/log/audit/audit.log?
ps -eZ | grep gitosis
Does this show apps running under the correct domain?
It's hard to tell whether it's running under the correct context (gitosis-serve seems to very quickly shell out to whatever git command is called and I'm not sure how to trigger ps at the correct time). However it definitely has the correct context on the executable (which is the only copy of gitosis-serve on the system), and I've relabeled the file system just to be sure.
However, I still seem to get the same AVC denial:
Summary:
SELinux is preventing bash (guest_t) "write" sshd_t.
Detailed Description:
SELinux denied access requested by bash. It is not expected that this access is required by bash and this access may signal an intrusion attempt. It is also possible that the specific version or configuration of the application is causing it to require additional access.
Allowing Access:
You can generate a local policy module to allow this access - see FAQ (http://fedora.redhat.com/docs/selinux-faq-fc5/#id2961385) Or you can disable SELinux protection altogether. Disabling SELinux protection is not recommended. Please file a bug report (http://bugzilla.redhat.com/bugzilla/enter_bug.cgi) against this package.
Additional Information:
Source Context guest_u:guest_r:guest_t:s0 Target Context system_u:system_r:sshd_t:s0-s0:c0.c1023 Target Objects pipe [ fifo_file ] Source bash Source Path /bin/bash Port<Unknown> Host hzhangpg02.ph.man.ac.uk Source RPM Packages bash-4.0-6.fc11 Target RPM Packages Policy RPM selinux-policy-3.6.12-62.fc11 Selinux Enabled True Policy Type targeted MLS Enabled True Enforcing Mode Enforcing Plugin Name catchall Host Name hzhangpg02.ph.man.ac.uk Platform Linux hzhangpg02.ph.man.ac.uk 2.6.29.5-191.fc11.x86_64 #1 SMP Tue Jun 16 23:23:21 EDT 2009 x86_64 x86_64 Alert Count 31 First Seen Tue 30 Jun 2009 16:48:17 BST Last Seen Tue 07 Jul 2009 10:51:13 BST Local ID 1cf6580e-12c8-48fb-bbb8-c06c3e55109d Line Numbers
Raw Audit Messages
node=hzhangpg02.ph.man.ac.uk type=AVC msg=audit(1246960273.947:80): avc: denied { write } for pid=3472 comm="bash" path="pipe:[51971]" dev=pipefs ino=51971 scontext=guest_u:guest_r:guest_t:s0 tcontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 tclass=fifo_file
node=hzhangpg02.ph.man.ac.uk type=AVC msg=audit(1246960273.947:80): avc: denied { write } for pid=3472 comm="bash" path="pipe:[51972]" dev=pipefs ino=51972 scontext=guest_u:guest_r:guest_t:s0 tcontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 tclass=fifo_file
node=hzhangpg02.ph.man.ac.uk type=SYSCALL msg=audit(1246960273.947:80): arch=c000003e syscall=59 success=yes exit=0 a0=7f5e932395d0 a1=7ffff16ddc90 a2=7f5e932314c0 a3=7ffff16dd940 items=0 ppid=3471 pid=3472 auid=501 uid=501 gid=501 euid=501 suid=501 fsuid=501 egid=501 sgid=501 fsgid=501 tty=(none) ses=5 comm="bash" exe="/bin/bash" subj=guest_u:guest_r:guest_t:s0 key=(null)
Piping the raw audit messages into audit2allow and installing the module doesn't seem to remove them, though.
Regards, Jon
So you intended on using the guest_t user? What does the te file created by audit2allow look like?
I think the problem here is the guest_t user is running at s0 and trying to write to a fifo_file at s0-s0:c0.c1023
If you take the above audit messages and run them through audit2why, what does the tool say?
2009/7/7 Daniel J Walsh dwalsh@redhat.com:
So you intended on using the guest_t user? What does the te file created by audit2allow look like?
I think the problem here is the guest_t user is running at s0 and trying to write to a fifo_file at s0-s0:c0.c1023
If you take the above audit messages and run them through audit2why, what does the tool say?
It says the errors were caused by: Was caused by: Policy constraint violation.
May require adding a type attribute to the domain or type to satisfy the constraint.
Constraints are defined in the policy sources in policy/constraints (general), policy/mcs (MCS), and policy/mls (MLS).
And when I run them through audit2why gives me
#============= guest_t ============== allow guest_t sshd_t:fifo_file write;
Which looks vaguely sane to my untrained eye.
I'm not particularly wedded to the guest user in specific, but I would prefer it to have a minimal privilege user, since it has no need to do anything but manage the git repositories in the home directory.
Regards Jon
On 07/07/2009 09:07 AM, Jonathan Stott wrote:
2009/7/7 Daniel J Walshdwalsh@redhat.com:
So you intended on using the guest_t user? What does the te file created by audit2allow look like?
I think the problem here is the guest_t user is running at s0 and trying to write to a fifo_file at s0-s0:c0.c1023
If you take the above audit messages and run them through audit2why, what does the tool say?
It says the errors were caused by: Was caused by: Policy constraint violation.
May require adding a type attribute to the domain or type to satisfy
the constraint.
Constraints are defined in the policy sources in policy/constraints
(general), policy/mcs (MCS), and policy/mls (MLS).
And when I run them through audit2why gives me
#============= guest_t ============== allow guest_t sshd_t:fifo_file write;
Which looks vaguely sane to my untrained eye.
I'm not particularly wedded to the guest user in specific, but I would prefer it to have a minimal privilege user, since it has no need to do anything but manage the git repositories in the home directory.
Regards Jon
No I think this is great, Just trying to figure out the best way to do this.
On 07/07/2009 09:07 AM, Jonathan Stott wrote:
2009/7/7 Daniel J Walshdwalsh@redhat.com:
So you intended on using the guest_t user? What does the te file created by audit2allow look like?
I think the problem here is the guest_t user is running at s0 and trying to write to a fifo_file at s0-s0:c0.c1023
If you take the above audit messages and run them through audit2why, what does the tool say?
It says the errors were caused by: Was caused by: Policy constraint violation.
May require adding a type attribute to the domain or type to satisfy
the constraint.
Constraints are defined in the policy sources in policy/constraints
(general), policy/mcs (MCS), and policy/mls (MLS).
And when I run them through audit2why gives me
#============= guest_t ============== allow guest_t sshd_t:fifo_file write;
Which looks vaguely sane to my untrained eye.
I'm not particularly wedded to the guest user in specific, but I would prefer it to have a minimal privilege user, since it has no need to do anything but manage the git repositories in the home directory.
Regards Jon
Ok I think the easiest thing for you to do now is change the range of the login user.
# semanage user -m -r s0-s0:c0.c1023 guest_u # semanage login -m -r s0-s0:c0.c1023 __default__
(If you use a user other then __default__ you would need to change this also.)
I will send a patch to F11 to allow communications to fifo_files running at different levels.
On 07/07/2009 04:28 PM, Daniel J Walsh wrote:
On 07/07/2009 09:07 AM, Jonathan Stott wrote:
2009/7/7 Daniel J Walshdwalsh@redhat.com:
So you intended on using the guest_t user? What does the te file created by audit2allow look like?
I think the problem here is the guest_t user is running at s0 and trying to write to a fifo_file at s0-s0:c0.c1023
If you take the above audit messages and run them through audit2why, what does the tool say?
It says the errors were caused by: Was caused by: Policy constraint violation.
May require adding a type attribute to the domain or type to
satisfy the constraint.
Constraints are defined in the policy sources in
policy/constraints (general), policy/mcs (MCS), and policy/mls (MLS).
And when I run them through audit2why gives me
#============= guest_t ============== allow guest_t sshd_t:fifo_file write;
Which looks vaguely sane to my untrained eye.
I'm not particularly wedded to the guest user in specific, but I would prefer it to have a minimal privilege user, since it has no need to do anything but manage the git repositories in the home directory.
Regards Jon
Ok I think the easiest thing for you to do now is change the range of the login user.
# semanage user -m -r s0-s0:c0.c1023 guest_u # semanage login -m -r s0-s0:c0.c1023 __default__
(If you use a user other then __default__ you would need to change this also.)
I will send a patch to F11 to allow communications to fifo_files running at different levels.
The patch has been added to selinux-policy-3.6.12-65.fc11
Regards Miroslav
-- fedora-selinux-list mailing list fedora-selinux-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-selinux-list
selinux@lists.fedoraproject.org