Description of problem: The /etc/xinetd.d/git file has some params that are not optimal for me. I use git-daemon with a strict SELinux config. Here is what i modified to make it play nice with my setup: [root@localhost xinetd.d]# less git # default: off # description: The git dæmon allows git repositories to be exported using \ # the git:// protocol. service git { disable = no socket_type = stream type = UNLISTED port = 9418 wait = no user = nobody # server = /usr/bin/git # server_args = daemon --base-path=/srv/git --export-all --user-path=public_git --syslog --inetd --verbose server = /usr/libexec/git-core/git-daemon server_args = --base-path=/srv/git --export-all --user-path=public_git --syslog --inetd --verbose log_on_failure += USERID # xinetd doesn't do this by default. bug #195265 flags = IPv6 } I do not see the "big benefit" of using /usr/sbin/git instead of /usr/libexec/git-core/git-daemon. By using the latter it will be easier to implement selinux security to git-daemon. If at all possible and sensible please use /usr/libexec/git-core/git-daemon
Not knowing much about how to run SELinux in strict mode, can you tell me more about what sort of errors/problems this causes. I'm not tied to using 'git daemon' necessarily, but it does help on the off chance that the path to git-daemon ever changes, as the git wrapper would handle it for us. I've also added Dan Walsh to the Cc, as he might be able to explain the pros and cons here as well. Thanks.
There is n o strict mode in Rawhide/F12. I think he means enforcing mode. What Errors were you seeing in /var/log/audit/audit.log
With strict mode i mean , SELinux targeted policy configured to behave like the old strict model. e.g. disable the unconfined module. (semodule -d unconfined) The problem is this: inetd_t runs git with the daemon option (this will transition to child_inetd_t domain), but the real git daemon is /usr/libexec/git-core/git-daemon. This means that a transition to a possible confined git-daemon domain can no longer happen. (since the caller is child_inetd_t and not inetd_t). I would have to label the git binary with another type to be able to make it transition to a confined domain. The problem is that i do not want (its a bad solution) to do this because the git binary is used by users for lots of things.
Also to dwalsh: we should label tcp:9418 git-daemon_port_t and give inetd_t access to bind tcp sockets to git-daemon_port_t. Currently git-daemon/xinetd can not bind to the network because xinetd is not allowed to bind tcp sockets to generic port_t type ports (currently tcp:9418 is unspecified e.g. port_t) Another git-daemon issue is: It was decided to label /var/lib/git httpd_git_content_t, to make cgit a confined apache cgi domain. I am not sure but is child_inetd_t allowed to read httpd_git_content_t? In production i can imagine that people want to use SELinux to protect their git-daemon environment or at the least not having to disable SELinux just to make git-daemon work. If they decide to do this they will hit a wall with these three issues i mentioned: 1. They will wonder why by default inetd_service_domain() domain will not work, unless they modify label /usr/bin/git (which is a program that should be type bin_t) or edit /etc/xinetd.d/git to point it to the "real" git-daemon. 2. They will have to manually allow inetd_t to bind tcp sockets to tcp:9418 which is a generic port with type port_t. (e.g. allow inetd_t broader network access than required), or manually declare a special port type for tcp:9418 and allow inetd_t to bind tcp sockets to this port type. 3. They will wonder why git-daemon cannot read /var/lib/git, which is the default configured location for shared repositories (since that location is currently labelled type httpd_git_content_t). They might have to allow child_inetd_t to be able to read this type, and might have to give git-shell accounts access to manage and execute this type (if they are not unconfined) All these issues can be overcome by seasoned SELinux administrators but the average Administrator might be tempted to make less optional security decisions or even disable SELinux security.
avc: denied { name_bind } for pid=2065 comm="xinetd" src=9418 scontext=staff_u:system_r:inetd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:port_t:s0 tclass=tcp_socket
Added git daemon policy in selinux-policy-3.6.32-31.fc12.noarch
For that policy to work, the server and server args directives have to be set to: server = /usr/libexec/git-core/git-daemon server_args = --base-path=/srv/git --export-all --user-path=public_git --syslog --inetd --verbose
Err, except --base-path which can be /var/lib/git... as packaged
This bug appears to have been reported against 'rawhide' during the Fedora 12 development cycle. Changing version to '12'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
This can be closed. Looks like it is fixed in: git-1.6.6.1-1.fc12 Use %{gitcoredir}/git-daemon as xinetd server option, for SELinux (#529682)
Heh, I was just about to submit that update via bodhi, so be prepared for a bit more bugzilla spam. Confirmation in bodhi that this works as intended would be most welcome. Thanks for working on this Dominick and Dan. Better git-daemon policy is a very nice addition to SELinux!
git-1.6.6.1-1.fc12 has been submitted as an update for Fedora 12. http://admin.fedoraproject.org/updates/git-1.6.6.1-1.fc12
git-1.6.6.1-1.fc12 has been pushed to the Fedora 12 stable repository. If problems still persist, please make note of it in this bug report.