Bug 521087 - failure of get_default_context_with_level(3) causes several curl tests to be skipped
Summary: failure of get_default_context_with_level(3) causes several curl tests to be ...
Alias: None
Product: Fedora
Classification: Fedora
Component: openssh
Version: 11
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Jan F. Chadima
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2009-09-03 15:16 UTC by Kamil Dudka
Modified: 2009-09-04 10:48 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2009-09-04 06:57:17 UTC

Attachments (Terms of Use)
sshd_config (1.49 KB, text/plain)
2009-09-03 15:16 UTC, Kamil Dudka
no flags Details
curl_sftp_config (1.22 KB, text/plain)
2009-09-03 18:02 UTC, Kamil Dudka
no flags Details

Description Kamil Dudka 2009-09-03 15:16:04 UTC
Created attachment 359693 [details]

Description of problem:
debug1: SELinux support enabled
ssh_selinux_getctxbyname: Failed to get default SELinux security context for xdudka00
Error sending audit message.
ssh_selinux_setup_exec_context: SELinux failure. Aborting connection.

Version-Release number of selected component (if applicable):

How reproducible:
Always when SELinux is set to enforcing mode.

Steps to Reproduce:
1. build F-11 curl
2. cd curl-7.19.6/tests
3. ./runtests.pl 603
Actual results:
(gdb) n
258             if (r == 0) {
260                     r = get_default_context_with_level(sename, lvl, NULL, 
(gdb) n
266             if (r == 0) {
(gdb) n
308             if (r != 0) {
(gdb) n
309                     error("%s: Failed to get default SELinux security "
(gdb) print lvl
$1 = 0x7f60d2b44a50 "s0-s0:c0.c1023"
(gdb) print sename
$2 = 0x7f60d2b3ccb0 "unconfined_u"
(gdb) print default_sc
$3 = (security_context_t *) 0x7fffaba2b808
(gdb) f
#0  ssh_selinux_getctxbyname (pwname=0x7f60d2b3d030 "xdudka00", 
default_sc=0x7fffaba2b808, user_sc=0x7fffaba2b800) at port-linux.c:309
309                     error("%s: Failed to get default SELinux security "
(gdb) print r
$4 = -1
(gdb) print *default_sc
$5 = (security_context_t) 0x0

Additional info:
I am able to pass over this with the following patch even in the enforcing SELinux mode:

--- a/openbsd-compat/port-linux.c
+++ b/openbsd-compat/port-linux.c
@@ -406,7 +406,7 @@ ssh_selinux_setup_exec_context(char *pwname)
        send_audit_message(r >= 0, default_ctx, user_ctx);
    if (r < 0) {
-       switch (security_getenforce()) {
+       switch (0/*security_getenforce()*/) {
        case -1:
            fatal("%s: security_getenforce() failed", __func__);
        case 0:

Comment 1 Tomas Mraz 2009-09-03 15:33:30 UTC
That seems like either problem directly in the curl test but even more probably something wrong with your testing environment.

Comment 2 Kamil Dudka 2009-09-03 16:31:58 UTC
Any idea how to change the testing environment to make the test suite happy?

Do you know why get_default_context_with_level() is called by sshd?

Which arguments does it expect to not fail?

Any chance to get over the failure e.g. by use of chcon/runcon?

Comment 3 Kamil Dudka 2009-09-03 18:02:26 UTC
Created attachment 359710 [details]

To exclude curl test-suite bug, here is a minimal example:

sshd -e -D -f curl_sshd_config \
    & sleep 1 \
    && sftp -b curl_sftp_cmds -F curl_sftp_config -S /usr/bin/ssh

Comment 4 Tomas Mraz 2009-09-04 06:57:17 UTC
You cannot run sshd directly this way without not breaking SELinux. You have to run SELinux either in permissive mode or you have run the sshd in the domain system_r:sshd_t.

You can try creating runsshd script with:
/usr/sbin/sshd -e -D -f curl_sshd_config

chcon the runsshd script to initrc_exec_t. And run it as
runcon -r system_r -t initrc_t ./runsshd
It should automatically transition the sshd to sshd_t.

Comment 5 Kamil Dudka 2009-09-04 10:17:48 UTC
Thanks! This works. I only needed to chcon log/sshd.log to initrc_exec_t as well to be writable by the SSH server.

Comment 6 Tomas Mraz 2009-09-04 10:48:29 UTC
I'd suggest to use sshd_var_run_t for the sshd.log as the initrc_exec_t might not be writable by sshd_t in future.

Note You need to log in before you can comment on or make changes to this bug.