Bug 518118 - SELinux prevents pppd from updating /etc/resolv.conf
Summary: SELinux prevents pppd from updating /etc/resolv.conf
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: selinux-policy
Version: 11
Hardware: All
OS: Linux
low
medium
Target Milestone: ---
Assignee: Miroslav Grepl
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2009-08-19 00:26 UTC by Nicola Soranzo
Modified: 2009-12-21 14:21 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2009-12-21 14:21:46 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Nicola Soranzo 2009-08-19 00:26:06 UTC
Description of problem:


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


How reproducible:


Steps to Reproduce:
1.
2.
3.
  
Actual results:


Expected results:


Additional info:

Comment 1 Nicola Soranzo 2009-08-19 00:38:50 UTC
Sorry, I pressed Enter at the wrong moment!

Description of problem:
In enforcing mode I can not correctly connect to Internet with PPP over ATM by using "ifup ppp0", even with sudo or as root. In /var/log/messages :

Aug 19 02:09:48 ozzy pppd[3921]: Warning: can't open options file /root/.ppprc: Permission denied
Aug 19 02:09:48 ozzy pppd[3921]: Plugin pppoatm.so loaded.
Aug 19 02:09:48 ozzy pppd[3921]: PPPoATM plugin_init
Aug 19 02:09:48 ozzy pppd[3921]: PPPoATM setdevname_pppoatm - SUCCESS:8.35
Aug 19 02:09:48 ozzy pppd[3921]: pppd 2.4.4 started by root, uid 0
Aug 19 02:09:48 ozzy pppd[3921]: Using interface ppp0
Aug 19 02:09:48 ozzy pppd[3921]: Connect: ppp0 <--> 8.35
Aug 19 02:09:48 ozzy pppd[3921]: Couldn't increase MTU to 1500. Using 1492
Aug 19 02:09:48 ozzy pppd[3921]: Couldn't increase MRU to 1500. Using 1492
Aug 19 02:09:51 ozzy pppd[3921]: Couldn't increase MTU to 1500. Using 1492
Aug 19 02:09:51 ozzy pppd[3921]: Couldn't increase MRU to 1500. Using 1492
Aug 19 02:09:51 ozzy pppd[3921]: Couldn't increase MTU to 1500. Using 1492
Aug 19 02:09:51 ozzy pppd[3921]: Couldn't increase MRU to 1500. Using 1492
Aug 19 02:09:52 ozzy pppd[3921]: PAP authentication succeeded
Aug 19 02:09:52 ozzy pppd[3921]: local  IP address 93.145.225.254
Aug 19 02:09:52 ozzy pppd[3921]: remote IP address 93.145.224.1
Aug 19 02:09:52 ozzy pppd[3921]: primary   DNS address 91.80.36.134
Aug 19 02:09:52 ozzy pppd[3921]: secondary DNS address 91.80.36.135
Aug 19 02:09:52 ozzy pppd[3933]: Can't execute /etc/ppp/ip-up: Permission denied

The connection is up (as proved by pinging a known IP address), but /etc/resolv.conf is not updated.
Similarly, when executing "ifdown ppp0", this message appears:

Aug 19 02:13:59 ozzy pppd[3985]: Can't execute /etc/ppp/ip-down: Permission denied

Instead, in permissive mode, "ifup ppp0" works even as normal user, and the last log message would be:

Aug 19 02:16:09 ozzy NET[4011]: /etc/sysconfig/network-scripts/ifup-post : updated /etc/resolv.conf

There are no AVC messages in permissive mode.


Version-Release number of selected component (if applicable):
selinux-policy-3.6.12-72
selinux-policy-targeted-3.6.12-72
ppp-2.4.4-11


How reproducible:
Always


Steps to Reproduce:
1. ifup ppp0


Actual results:
ping www.google.com does not work


Expected results:
Updated DNS in /etc/resolv.conf 


Additional info:
Permissions of some files:
-rwxr-xr-x. root root system_u:object_r:pppd_initrc_exec_t:SystemLow /etc/ppp/ip-down
-rwxr-xr-x. root root system_u:object_r:pppd_initrc_exec_t:SystemLow /etc/ppp/ip-up
-r-xr-xr-x. root root system_u:object_r:pppd_exec_t:SystemLow /usr/sbin/pppd

Comment 2 Daniel Walsh 2009-08-19 21:07:28 UTC
What avc messages are you seeing in /var/log/audit/audit.log
What is the label on /etc/resolv.conf

Comment 3 Nicola Soranzo 2009-08-19 22:56:35 UTC
(In reply to comment #2)
> What avc messages are you seeing in /var/log/audit/audit.log

type=SELINUX_ERR msg=audit(1250722530.252:33399): security_compute_sid:  invalid context unconfined_u:unconfined_r:initrc_t:s0-s0:c0.c1023 for scontext=unconfined_u:unconfined_r:pppd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:pppd_initrc_exec_t:s0 tclass=process
type=SYSCALL msg=audit(1250722530.252:33399): arch=40000003 syscall=11 success=no exit=-13 a0=b187b8 a1=bfd5c1cc a2=1c73018 a3=0 items=0 ppid=2964 pid=2976 auid=500 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=1 comm="pppd" exe="/usr/sbin/pppd" subj=unconfined_u:unconfined_r:pppd_t:s0-s0:c0.c1023 key=(null)

> What is the label on /etc/resolv.conf  

-rw-r--r--. root root system_u:object_r:net_conf_t:SystemLow /etc/resolv.conf

Comment 4 Daniel Walsh 2009-08-20 12:08:16 UTC
If you create a file called myppp.te

================================ cut =================================
policy_module(myppp,1.0)
gen_require(`
           type pppd_t;
')

init_script_role_transition(pppd_t)

=======================================================================

Then execute

# make -f /usr/share/selinux/devel/Makefile
# semodule -i myppp.pp

And try it again. 

If this works we can make it part of the general policy.

Comment 5 Daniel Walsh 2009-08-20 12:40:58 UTC
Ignore the previous this will not work.

Could someone from ppp please explain how this works?

Does a user execute pppd, and then some how this starts an init service pppd?

Comment 6 Nicola Soranzo 2009-08-23 15:39:28 UTC
That's what I can reconstruct:

/sbin/ifup ppp0

calls:

/etc/sysconfig/network-scripts/ifup-ppp

which in turn calls:

adsl-start /etc/sysconfig/network-scripts/ifcfg-ppp0

which in turn calls:

/sbin/pppoe-connect /etc/sysconfig/network-scripts/ifcfg-ppp0

which finally calls:

/usr/sbin/pppd ipparam ppp0 linkname ppp0 plugin pppoatm.so 8.35 noipdefault noauth default-asyncmap defaultroute hide-password nodetach usepeerdns ...

Then I don't know...

Comment 7 Nicola Soranzo 2009-08-24 18:43:19 UTC
I downloaded ppp-2.4.4 sources, the error string "Can't execute" is from function

run_program(prog, args, must_exist, done, arg, wait)

in file pppd/main.c which is called by function ipcp_script() with these arguments:

prog = /etc/ppp/ip-up
must_exist = 0
done = ipcp_script_done
arg = NULL
wait = 0

That's the run_program function:

/*
 * run-program - execute a program with given arguments,
 * but don't wait for it unless wait is non-zero.
 * If the program can't be executed, logs an error unless
 * must_exist is 0 and the program file doesn't exist.
 * Returns -1 if it couldn't fork, 0 if the file doesn't exist
 * or isn't an executable plain file, or the process ID of the child.
 * If done != NULL, (*done)(arg) will be called later (within
 * reap_kids) iff the return value is > 0.
 */
pid_t
run_program(prog, args, must_exist, done, arg, wait)
    char *prog;
    char **args;
    int must_exist;
    void (*done) __P((void *));
    void *arg;
    int wait;
{
    int pid, status;
    struct stat sbuf;

    /*
     * First check if the file exists and is executable.
     * We don't use access() because that would use the
     * real user-id, which might not be root, and the script
     * might be accessible only to root.
     */
    errno = EINVAL;
    if (stat(prog, &sbuf) < 0 || !S_ISREG(sbuf.st_mode)
	|| (sbuf.st_mode & (S_IXUSR|S_IXGRP|S_IXOTH)) == 0) {
	if (must_exist || errno != ENOENT)
	    warn("Can't execute %s: %m", prog);
	return 0;
    }

    pid = safe_fork(fd_devnull, fd_devnull, fd_devnull);
    if (pid == -1) {
	error("Failed to create child process for %s: %m", prog);
	return -1;
    }
    if (pid != 0) {
	if (debug)
	    dbglog("Script %s started (pid %d)", prog, pid);
	record_child(pid, prog, done, arg);
	if (wait) {
	    while (waitpid(pid, &status, 0) < 0) {
		if (errno == EINTR)
		    continue;
		fatal("error waiting for script %s: %m", prog);
	    }
	    forget_child(pid, status);
	}
	return pid;
    }

    /* Leave the current location */
    (void) setsid();	/* No controlling tty. */
    (void) umask (S_IRWXG|S_IRWXO);
    (void) chdir ("/");	/* no current directory. */
    setuid(0);		/* set real UID = root */
    setgid(getegid());

#ifdef BSD
    /* Force the priority back to zero if pppd is running higher. */
    if (setpriority (PRIO_PROCESS, 0, 0) < 0)
	warn("can't reset priority to 0: %m");
#endif

    /* run the program */
    execve(prog, args, script_env);
    if (must_exist || errno != ENOENT) {
	/* have to reopen the log, there's nowhere else
	   for the message to go. */
	reopen_log();
	syslog(LOG_ERR, "Can't execute %s: %m", prog);
	closelog();
    }
    _exit(-1);
}

Comment 8 Daniel Walsh 2009-08-25 13:41:34 UTC
I guess I am trying to figure out if we can run the ppp command without a transition and allow normal starting of a service to work.

I am removing

ppp_run(unconfined_t, unconfined_r)

from rawhide, to see if this will work properly without the transition.

Comment 9 Nicola Soranzo 2009-08-27 12:29:04 UTC
(In reply to comment #8)
> I guess I am trying to figure out if we can run the ppp command without a
> transition and allow normal starting of a service to work.
> 
> I am removing
> 
> ppp_run(unconfined_t, unconfined_r)
> 
> from rawhide, to see if this will work properly without the transition.  

In fact, this bug was introduced between selinux-policy-3.6.12-39.fc11 and 3.6.12-53.fc11 , and the line you mention was added in 3.6.12-52 :

http://cvs.fedoraproject.org/viewvc/rpms/selinux-policy/F-11/policy-20090521.patch?revision=1.13&view=markup&pathrev=selinux-policy-3_6_12-52_fc11

Comment 10 Daniel Walsh 2009-08-28 13:29:21 UTC
I think the reason for this was that /etc/resolv.conf was being created with the wrong context.  I think we should remove the transition and see what happens, since what we have is obviously wrong.

Comment 11 Miroslav Grepl 2009-09-02 14:11:55 UTC
The transition removed in selinux-policy-3.6.12-82.fc11

Comment 12 Nicola Soranzo 2009-09-03 08:23:26 UTC
I can confirm that removing this transition fixes the bug!
Thank you very much!


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