Re: DSA 557-1 and CAN-2004-0564
On Mon, Oct 04, 2004 at 12:14:56PM -0400, Christian Hudon wrote:
Max Vozeler wrote:
The pppd in Debian appears to change privileges back to those of the
invoking user before calling the program specified in the pty option,
preventing normal users from controlling PPPOE connections like other
normal PPP connections.
If this is really the case, then maybe the best solution would be to
modify that Debian patch to pppd to add a dont-drop-root-privs
option to the pty option? Then people using pppd together with pppoe
could use that option, pppoe would be run as root, and people in group
dip would be able to launch PPP connections.
How about something like the attached?
It introduces a new option pty-keep-privs which tells pppd to keep
euid=0 when calling the pty script. The option is privileged so that
only root can change it. Like other privileged options it can also be
specified in the /etc/ppp/peers/ configs.
pty /usr/sbin/pppoe ...
pty-keep-privs
It would make it possible for /usr/sbin/pppoe to get rid of setuid root
and still work for unprivileged users. Marco, how does this look to you?
Would you consider including such an option in ppp?
Cheers,
Max
--
308E81E7B97963BCA0E6ED889D5BD511B7CDA2DC
--- build-tree/ppp/pppd/main.c 2004-10-05 14:01:33.0 +0200
+++ ppp/pppd/main.c 2004-10-05 14:02:10.0 +0200
@@ -1512,10 +1512,11 @@
* stderr gets connected to the log fd or to the _PATH_CONNERRS file.
*/
int
-device_script(program, in, out, dont_wait)
+device_script(program, in, out, dont_wait, keep_privs)
char *program;
int in, out;
int dont_wait;
+int keep_privs;
{
int pid;
int status = -1;
@@ -1591,12 +1592,15 @@
close(errfd);
}
-setuid(uid);
-if (getuid() != uid) {
- error(setuid failed);
- exit(1);
+if (keep_privs != 1) {
+setuid(uid);
+if (getuid() != uid) {
+error(setuid failed);
+exit(1);
+}
+setgid(getgid());
}
-setgid(getgid());
+
execl(/bin/sh, sh, -c, program, (char *)0);
error(could not exec /bin/sh: %m);
exit(99);
--- build-tree/ppp/pppd/pppd.8 2004-10-05 14:01:34.0 +0200
+++ ppp/pppd/pppd.8 2004-10-05 14:02:31.0 +0200
@@ -904,6 +904,11 @@
\fIrecord\fR option is used in conjuction with the \fIpty\fR option,
the child process will have pipes on its standard input and output.)
.TP
+.B pty-keep-privs
+Specifies that pppd should keep root privileges when calling the
+script given in the \fIpty\fR option. This option is privileged and
+may only be specified by root or in a system-wide configuration file.
+.TP
.B receive-all
With this option, pppd will accept all control characters from the
peer, including those marked in the receive asyncmap. Without this
--- build-tree/ppp/pppd/pppd.h 2004-10-05 14:01:34.0 +0200
+++ ppp/pppd/pppd.h 2004-10-05 14:02:10.0 +0200
@@ -469,7 +469,8 @@
/* Cancel call to func(arg) */
void record_child __P((int, char *, void (*) (void *), void *));
pid_t safe_fork __P((void)); /* Fork close stuff in child */
-int device_script __P((char *cmd, int in, int out, int dont_wait));
+int device_script __P((char *cmd, int in, int out, int dont_wait,
+int keep_privs));
/* Run `cmd' with given stdin and stdout */
pid_t run_program __P((char *prog, char **args, int must_exist,
void (*done)(void *), void *arg));
--- build-tree/ppp/pppd/tty.c 2004-01-17 06:50:12.0 +0100
+++ ppp/pppd/tty.c 2004-10-05 14:02:10.0 +0200
@@ -148,6 +148,7 @@
char *disconnect_script = NULL; /* Script to disestablish physical link */
char *welcomer = NULL; /* Script to run after phys link estab. */
char *ptycommand = NULL; /* Command to run on other side of pty */
+bool pty_privileged = 0; /* Keep euid=0 when calling pty program */
bool notty = 0; /* Stdin/out is not a tty */
char *record_file = NULL;/* File to record chars sent/received */
intmax_data_rate; /* max bytes/sec through charshunt */
@@ -196,6 +197,10 @@
Script to run on pseudo-tty master side,
OPT_PRIO | OPT_PRIVFIX | OPT_DEVNAM },
+{ pty-keep-privs, o_bool, pty_privileged,
+ Keep root privileges when calling the pty program,
+ OPT_PRIO | OPT_PRIV | 1 },
+
{ notty, o_bool, notty,
Input/output is not a tty, OPT_DEVNAM | 1 },
@@ -627,7 +632,7 @@
(void) fcntl(ipipe[0], F_SETFD, FD_CLOEXEC);
(void) fcntl(opipe[1], F_SETFD, FD_CLOEXEC);
- ok = device_script(ptycommand, opipe[0], ipipe[1], 1) == 0
+ ok = device_script(ptycommand, opipe[0], ipipe[1], 1,
pty_privileged) == 0
start_charshunt(ipipe[0], opipe[1]);
close(ipipe[0]);
Re: DSA 557-1 and CAN-2004-0564
On Wed, 06 Oct 2004, Marco d'Itri wrote: On Oct 06, Max Vozeler [EMAIL PROTECTED] wrote: It would make it possible for /usr/sbin/pppoe to get rid of setuid root and still work for unprivileged users. Marco, how does this look to you? Would you consider including such an option in ppp? I think I'm missing something. What's wrong with pppoe being setuid? Anyway, pppoe is deprecated and superseded by the kernel-space driver, so I'm not much interested in hacking pppd for its benefit. Is it, really? Last time I checked, the kernel driver was not considered as stable. I sure hope this changed, but... -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: DSA 557-1 and CAN-2004-0564
On Wed, Oct 06, 2004 at 02:11:32PM +0200, Marco d'Itri wrote: On Oct 06, Max Vozeler [EMAIL PROTECTED] wrote: It would make it possible for /usr/sbin/pppoe to get rid of setuid root and still work for unprivileged users. Marco, how does this look to you? Would you consider including such an option in ppp? I think I'm missing something. What's wrong with pppoe being setuid? Upstream says it wasn't designed for that (see the beginning of the thread on debian-security [1]) so there may well be other security bugs lurking. Anyway, pppoe is deprecated and superseded by the kernel-space driver, so I'm not much interested in hacking pppd for its benefit. I don't know much about that, but pppoe is still installed on a great many system (#390 in popcon). Having something like the pty-keep-privs option would bring a potentially big improvement for security of those systems. Cheers, Max [1] http://lists.debian.org/debian-security/2004/10/msg4.html -- 308E81E7B97963BCA0E6ED889D5BD511B7CDA2DC -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: DSA 557-1 and CAN-2004-0564
David F. Skoll wrote: On Mon, 4 Oct 2004, Martin Schulze wrote: There are reasons users install it setuid / setgid, and these installations are vulnerable. I disagree. There is absolutely *no* reason to install rp-pppoe setuid-root. It is normally invoked by pppd, and pppd must be either invoked by root or setuid-root itself. Could you name a scenario in which a setuid-root rp-pppoe is needed? Please talk to the Debian maintainer of rp-pppoe since pppoe is installed root.dip and setuid in Debian sarge and sid. The maintainer can be reached through [EMAIL PROTECTED] Details about this package can be found here: http://packages.debian.org/pppoe Regards, Joey -- Everybody talks about it, but nobody does anything about it! -- Mark Twain Please always Cc to me when replying to me on the lists. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: DSA 557-1 and CAN-2004-0564
Hi David, On Mon, Oct 04, 2004 at 10:27:28AM -0400, David F. Skoll wrote: On Mon, 4 Oct 2004, Martin Schulze wrote: There are reasons users install it setuid / setgid, and these installations are vulnerable. I disagree. There is absolutely *no* reason to install rp-pppoe setuid-root. It is normally invoked by pppd, and pppd must be either invoked by root or setuid-root itself. Could you name a scenario in which a setuid-root rp-pppoe is needed? The pppd in Debian appears to change privileges back to those of the invoking user before calling the program specified in the pty option, preventing normal users from controlling PPPOE connections like other normal PPP connections. Eg: | I have a user which is a member of the dip group. This should | allow him to use pon dsl-provider to dial in. However, a | permission problem prevents this: pppd drops too many provileges | before it starts pppoe! (from http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=172376) Then again since you recommend against giving it setuid root, there may be other unforseen effects in the Debian package besides the file creation/ overwriting that I noticed. Cheers, Max -- 308E81E7B97963BCA0E6ED889D5BD511B7CDA2DC -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: DSA 557-1 and CAN-2004-0564
Max Vozeler wrote: The pppd in Debian appears to change privileges back to those of the invoking user before calling the program specified in the pty option, preventing normal users from controlling PPPOE connections like other normal PPP connections. If this is really the case, then maybe the best solution would be to modify that Debian patch to pppd to add a dont-drop-root-privs option to the pty option? Then people using pppd together with pppoe could use that option, pppoe would be run as root, and people in group dip would be able to launch PPP connections. Christian -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
