Need for pppd to be setuid root

[Sumanth Naropanth]

Many Linux distros (perhaps all) no longer ship pppd as setuid root.
But doesn't this restrict the usage of pppd only to root? Are there
specific security issues in having pppd setuid root?

Regards,
Sumanth

[Unruh]

Post by Sumanth Naropanth
Many Linux distros (perhaps all) no longer ship pppd as setuid root.
But doesn't this restrict the usage of pppd only to root? Are there
specific security issues in having pppd setuid root?

This has been a long standing practice. My standard is to change it first
thing to suid root. I have no idea why they ship it in this way, since pppd
needs to be root to change the routing tables, etc.
There are security issues with anything running suid root. However pppd is
no worse than others. The developers have spent some time trying to make
sure that it is safe. No guarentee, but...

Post by Sumanth Naropanth
Regards,
Sumanth

[Moe Trin]

On 3 Jun 2006, in the Usenet newsgroup comp.protocols.ppp, in article

Post by Unruh

Post by Sumanth Naropanth
Many Linux distros (perhaps all) no longer ship pppd as setuid root.

This has been a long standing practice. My standard is to change it first
thing to suid root. I have no idea why they ship it in this way, since pppd
needs to be root to change the routing tables, etc.

Yes, but it doesn't have to be SUID to run as root. As in my reply to
Sumanth, there are all kinds of these "helper" programs that may be SUID,
or may use 'userctl' or some other mechanism. Or, you can run it in demand
mode out of the boot scripts. If you recall, the original PPP-HOWTO from
Robert Hart from the mid-90s suggested making pppd 4750 root:PPP to limit
access/exposure, as did the README.linux file from Michael Callahan, Al
Longyear, and Paul Mackerras that came with early versions of ppp. The
current (2.4.x) README.linux file doesn't mention this technique.

Post by Unruh
There are security issues with anything running suid root. However pppd is
no worse than others. The developers have spent some time trying to make
sure that it is safe.

and I can only think of a couple of ways it _could_ be (not necessarily
"will be") abused.

Post by Unruh
No guarentee, but...

Exactly - so what's wrong with 'belt and suspenders'?

Old guy

[Unruh]

Post by Moe Trin
On 3 Jun 2006, in the Usenet newsgroup comp.protocols.ppp, in article

Post by Unruh

Post by Sumanth Naropanth
Many Linux distros (perhaps all) no longer ship pppd as setuid root.

This has been a long standing practice. My standard is to change it first
thing to suid root. I have no idea why they ship it in this way, since pppd
needs to be root to change the routing tables, etc.

Yes, but it doesn't have to be SUID to run as root. As in my reply to
Sumanth, there are all kinds of these "helper" programs that may be SUID,
or may use 'userctl' or some other mechanism. Or, you can run it in demand
mode out of the boot scripts. If you recall, the original PPP-HOWTO from
Robert Hart from the mid-90s suggested making pppd 4750 root:PPP to limit
access/exposure, as did the README.linux file from Michael Callahan, Al
Longyear, and Paul Mackerras that came with early versions of ppp. The
current (2.4.x) README.linux file doesn't mention this technique.

Post by Unruh
There are security issues with anything running suid root. However pppd is
no worse than others. The developers have spent some time trying to make
sure that it is safe.

and I can only think of a couple of ways it _could_ be (not necessarily
"will be") abused.

Post by Unruh
No guarentee, but...

Exactly - so what's wrong with 'belt and suspenders'?

If the belt and suspenders are cinched too tightly, you are liable to find
life uncomfortable

Post by Moe Trin
Old guy

[Unruh]

Post by Moe Trin
On 3 Jun 2006, in the Usenet newsgroup comp.protocols.ppp, in article

Post by Unruh

Post by Sumanth Naropanth
Many Linux distros (perhaps all) no longer ship pppd as setuid root.

This has been a long standing practice. My standard is to change it first
thing to suid root. I have no idea why they ship it in this way, since pppd
needs to be root to change the routing tables, etc.

Yes, but it doesn't have to be SUID to run as root. As in my reply to
Sumanth, there are all kinds of these "helper" programs that may be SUID,
or may use 'userctl' or some other mechanism. Or, you can run it in demand
mode out of the boot scripts. If you recall, the original PPP-HOWTO from
Robert Hart from the mid-90s suggested making pppd 4750 root:PPP to limit
access/exposure, as did the README.linux file from Michael Callahan, Al
Longyear, and Paul Mackerras that came with early versions of ppp. The
current (2.4.x) README.linux file doesn't mention this technique.

Most of those "helper" programs are far more dangerous as suid root than is
pppd. I would far rather trust the writers of pppd than of kppp to get it
right.

Post by Moe Trin

Post by Unruh
There are security issues with anything running suid root. However pppd is
no worse than others. The developers have spent some time trying to make
sure that it is safe.

and I can only think of a couple of ways it _could_ be (not necessarily
"will be") abused.

Post by Unruh
No guarentee, but...

Exactly - so what's wrong with 'belt and suspenders'?

pppd HAS to run as root to work. You can either have it run suid root, and
trust that the writers did their homework so that it runs as root only
while it has to accomplish its root tasks, or you have some other program
running as root so that pppd ALWAYS runs as root, and in addition you have
another program also running as root, doubling or much more the chance of
some exploitable bug.
If a program MUST run as root to accomplish part of its task, then it
should be suid root. IT can than be properly designed to run as root
onlywhile it needs to and it can then be designed to minimize the risk. If
you have something else running it as root, then pppd will always run as
root, and that other program also give opportunity for expoloits.

Post by Moe Trin
Old guy

[Moe Trin]

On 2 Jun 2006, in the Usenet newsgroup comp.protocols.ppp, in article

Post by Sumanth Naropanth
Many Linux distros (perhaps all) no longer ship pppd as setuid root.

I'm trying to remember the last time I saw a suid pppd - it's been a LONG
time - maybe back in the mid 1990s.

Post by Sumanth Naropanth
But doesn't this restrict the usage of pppd only to root?

No, the average distribution has a number of other ways around the
problem - everything from running in demand mode (started out of a
boot script) to eighty-seven jillion "helper" programs (many of which
are themselves running SUID, or are using 'userctl'), or have the
command run using 'sudo'.

Post by Sumanth Naropanth
Are there specific security issues in having pppd setuid root?

file name
Read options from file name (the format is described
below). The file must be readable by the user who has
invoked pppd.

privgroup group-name
Allows members of group group-name to use privileged
options. This is a privileged option. Use of this option
requires care as there is no guarantee that members of
group-name cannot use pppd to become root themselves. Con-
sider it equivalent to putting the members of group-name in
the kmem or disk group.

and see the man page section on "SECURITY", The advantage of the helper
programs is that they do not permit passing command line arguements to
pppd which could then be run as root. Likewise, _most_ of the helper
programs either don't accept command line arguements, or only accept a
limited selection. Not fool-proof, because they are constantly evolving
new, more inventive fools every day.

On the other hand, many of the popular Linux distributions are aimed at
the relatively in-experienced users. Twenty years ago, I went six months
without knowing anything about 'root' - and it was well over a year before
I got access to a very limited selection of administrative commands. I had
nearly two years experience before I got a root password. In Linux today,
that's the first account a new install creates for the user. A very
important factor in these distributions is protecting the new user from
inept use of root - perhaps as much as the basic security concerns.

Old guy

[James Carlson]

Post by Moe Trin

Post by Sumanth Naropanth
Are there specific security issues in having pppd setuid root?

file name
Read options from file name (the format is described
below). The file must be readable by the user who has
invoked pppd.

No, not a security problem. When options are read from any
non-privileged source, they cannot override the settings provided by
privileged functions.

You can do NOTHING via the 'file' option that you cannot do via the
command line itself.

Post by Moe Trin
privgroup group-name
Allows members of group group-name to use privileged
options. This is a privileged option. Use of this option

Privileged option; non-privileged users cannot invoke this.

Post by Moe Trin
and see the man page section on "SECURITY", The advantage of the helper
programs is that they do not permit passing command line arguements to
pppd which could then be run as root. Likewise, _most_ of the helper

That's an incorrect analysis. Command line arguments provided by
non-root users are _NEVER_ run as root by pppd.

[Moe Trin]

On 05 Jun 2006, in the Usenet newsgroup comp.protocols.ppp, in article

Post by James Carlson
No, not a security problem. When options are read from any
non-privileged source, they cannot override the settings provided by
privileged functions.

First, let me reiterate that my C skills are virtually non-existent. I'm
reading the man page, and playing. 'Privileged options may be used in
/etc/ppp/options file or in an options file read using the call option.'
My expectation is that the "last" occurrence of a specific option wins.
Looking at the 'connect' option, it says 'A value for this option from a
privileged source cannot be overridden by a non-privileged user'. Thus, if
the 'connect' and file option are in the same source, with the file option
occurring last, it could override the connect.

[compton ~]$ cat /usr/local/bin/dialin7test
exec /usr/sbin/pppd connect "/usr/sbin/chat -f /etc/ppp/dialscript7" file
/tmp/foo
[compton ~]$

(Obviously, that's all one line.) /tmp/foo contained another 'connect'
option

connect "/bin/echo poo > /tmp/bar ; /bin/chown 0:0 /tmp/bar"

and running dialin7test results in /usr/sbin/chat NOT running, and the
string 'poo' getting put into /tmp/bar, but the system is barfing over the
chown. /tmp/bar is created with ownership of the person running the
dialin7test script. This occurs with and without a '/dev/modem' line in
/etc/ppp/options, or a completely empty /etc/ppp/options file.

Post by James Carlson
Privileged option; non-privileged users cannot invoke this.

Understood. My concern with this option was if (for some strange reason)
root had included this option for what was seen as a legitimate reason.

Post by James Carlson
That's an incorrect analysis. Command line arguments provided by
non-root users are _NEVER_ run as root by pppd.

So it seems. None the less, the option substitution does occur. I don't
know how much further that can be taken.

Old guy

[Moe Trin]

By the way, I realize the example that I used isn't that great. What I
was trying to do quickly was to see the effect of the 'file' option
coming after a non-privileged command. My use of /usr/local/bin
is not relevant to that (users had better NOT have write permission
there) as I could as easily run it from a command line. Likewise, I'm
not entirely sure why a user should be able to write to the file
specified by the file option, but that's the local administrator's
decision, not mine.

Old guy

[James Carlson]

Post by Moe Trin
First, let me reiterate that my C skills are virtually non-existent. I'm
reading the man page, and playing. 'Privileged options may be used in
/etc/ppp/options file or in an options file read using the call option.'

That's correct.

The part I think you're missing is that only a privileged user can
create files in the /etc/ppp/peers/ directory, and that the 'call'
option only reads files from that directory. Thus, if such a file
exists and uses the "file" option, it's already a privileged (and
safe) source of options.

The command line and any options read via occurrences of the "file"
option found there are unprivileged.

Post by Moe Trin
My expectation is that the "last" occurrence of a specific option wins.

That's true unless the source is privileged.

Post by Moe Trin
Looking at the 'connect' option, it says 'A value for this option from a
privileged source cannot be overridden by a non-privileged user'. Thus, if
the 'connect' and file option are in the same source, with the file option
occurring last, it could override the connect.

No, it cannot.

The source of each option is examined. If the source is privileged,
then it can set or override the value. If the source is not
privileged, then it can set or override the value only if it has not
been set from a privileged source.

Post by Moe Trin
[compton ~]$ cat /usr/local/bin/dialin7test
exec /usr/sbin/pppd connect "/usr/sbin/chat -f /etc/ppp/dialscript7" file
/tmp/foo
[compton ~]$
(Obviously, that's all one line.) /tmp/foo contained another 'connect'
option
connect "/bin/echo poo > /tmp/bar ; /bin/chown 0:0 /tmp/bar"

Both of those options are unprivileged, because they're from
unprivileged sources.

Post by Moe Trin
and running dialin7test results in /usr/sbin/chat NOT running, and the
string 'poo' getting put into /tmp/bar, but the system is barfing over the
chown.

Right. See above. You haven't identified a security problem.

Also note that the connect option ('chat') is invoked as the invoking
user, not as root.

Post by Moe Trin
/tmp/bar is created with ownership of the person running the
dialin7test script. This occurs with and without a '/dev/modem' line in
/etc/ppp/options, or a completely empty /etc/ppp/options file.

Yep.

Still not a problem.

Now try creating a problem. Here are two cases to try out.

Case A

/etc/ppp/options contains:

file /tmp/foo

/tmp/foo contains:

connect "chat hi there"

Then, from the command line, do this:

% pppd connect "chat no way"

You'll find that the latter (command-line) connect is ignored,
because the former is from a privileged source.

Case B

touch /etc/ppp/options

/etc/ppp/peers/bar contains:

file /tmp/blah

/tmp/blah contains:

connect "chat this works"

/tmp/flop contains:

connect "chat this does not"

Then, from the command line, try:

% pppd call bar file /tmp/flop

Post by Moe Trin

Post by James Carlson
Privileged option; non-privileged users cannot invoke this.

Understood. My concern with this option was if (for some strange reason)
root had included this option for what was seen as a legitimate reason.

If it does, then an ordinary user cannot override it.

Post by Moe Trin

Post by James Carlson
That's an incorrect analysis. Command line arguments provided by
non-root users are _NEVER_ run as root by pppd.

So it seems. None the less, the option substitution does occur. I don't
know how much further that can be taken.

Please read the documentation more carefully. Some option sources
(those that can be written directly only by an administrator) are
considered privileged. Other option sources (those that can be
changed by ordinary users) are not.

The latter cannot override the former.

This is entirely by design. Please: if you're going to make claims
about insecurity, investigate them very carefully first. It takes
only a few written words based on a flawed analysis to cause all sorts
of alarm bells to go off errantly, and to cause dozens or hundreds of
people to be forced to do unnecessary and pointless work cleaning up
the resulting mess.

[Moe Trin]

On 06 Jun 2006, in the Usenet newsgroup comp.protocols.ppp, in article

Post by James Carlson
The part I think you're missing is that only a privileged user can
create files in the /etc/ppp/peers/ directory,

No, I'm not missing that at all. The only directories outside of their
home directory that our users have write access to is /tmp/ and /var/tmp,
and we even discourage using those - the default here sets up a ~/tmp
instead.

Post by James Carlson
The command line and any options read via occurrences of the "file"
option found there are unprivileged.

That's my understanding

Post by James Carlson
The source of each option is examined. If the source is privileged,
then it can set or override the value. If the source is not
privileged, then it can set or override the value only if it has not
been set from a privileged source.

That's also my understanding

Post by James Carlson
Also note that the connect option ('chat') is invoked as the invoking
user, not as root.

I can see that with the result of the extra connect that ran the echo
command, but didn't quite understand why the date stamps on the modem
device where changing in normal operation. (The modem permissions on
these systems are all 640 and root:root, yet the mtime on the device
is changed at the beginning and end of the call.) It dawns on me that
chat is talking to stdio, and pppd is redirecting the I/O. The effect
I was seeing in the creation of the file in /tmp being owned by the
running user was because the bogus connect option was being redirected
directly in that script, rather than having pppd do the redirection.

Old guy

[James Carlson]

Post by Moe Trin
I can see that with the result of the extra connect that ran the echo
command, but didn't quite understand why the date stamps on the modem
device where changing in normal operation. (The modem permissions on
these systems are all 640 and root:root, yet the mtime on the device
is changed at the beginning and end of the call.)

That's annoying, but updating the mtime is a UNIX standards compliance
requirement.

Post by Moe Trin
It dawns on me that
chat is talking to stdio, and pppd is redirecting the I/O.

Yes.

Post by Moe Trin
The effect
I was seeing in the creation of the file in /tmp being owned by the
running user was because the bogus connect option was being redirected
directly in that script, rather than having pppd do the redirection.

Right.