Need for pppd to be setuid root - PPP

This is a discussion on Need for pppd to be setuid root - PPP ; 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...

+ Reply to Thread
Results 1 to 11 of 11

Thread: Need for pppd to be setuid root

  1. Need for pppd to be setuid root

    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


  2. Re: Need for pppd to be setuid root

    "Sumanth Naropanth" writes:

    >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...


    >Regards,
    >Sumanth



  3. Re: Need for pppd to be setuid root

    On 2 Jun 2006, in the Usenet newsgroup comp.protocols.ppp, in article
    <1149281457.447130.235280@i39g2000cwa.googlegroups. com>, Sumanth Naropanth
    wrote:

    >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.

    >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'.

    >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

  4. Re: Need for pppd to be setuid root

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

    >"Sumanth Naropanth" writes:
    >
    >>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.

    >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.

    >No guarentee, but...


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

    Old guy

  5. Re: Need for pppd to be setuid root

    ibuprofin@painkiller.example.tld (Moe Trin) writes:

    >On 3 Jun 2006, in the Usenet newsgroup comp.protocols.ppp, in article
    >, Unruh wrote:


    >>"Sumanth Naropanth" writes:
    >>
    >>>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.


    >>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.


    >>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

    > Old guy


  6. Re: Need for pppd to be setuid root

    ibuprofin@painkiller.example.tld (Moe Trin) writes:

    >On 3 Jun 2006, in the Usenet newsgroup comp.protocols.ppp, in article
    >, Unruh wrote:


    >>"Sumanth Naropanth" writes:
    >>
    >>>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.


    >>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.


    >>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.



    > Old guy


  7. Re: Need for pppd to be setuid root

    On 05 Jun 2006, in the Usenet newsgroup comp.protocols.ppp, in article
    , James Carlson wrote:

    >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.

    >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.

    >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

  8. Re: Need for pppd to be setuid root

    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

  9. Re: Need for pppd to be setuid root

    ibuprofin@painkiller.example.tld (Moe Trin) writes:
    > 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.

    > My expectation is that the "last" occurrence of a specific option wins.


    That's true unless the source is privileged.

    > 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.

    > [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.

    > 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.

    > /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

    > >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.

    > >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.

    --
    James Carlson, KISS Network
    Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084
    MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677

  10. Re: Need for pppd to be setuid root

    On 06 Jun 2006, in the Usenet newsgroup comp.protocols.ppp, in article
    , James Carlson wrote:

    >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.

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


    That's my understanding

    >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

    >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

  11. Re: Need for pppd to be setuid root

    ibuprofin@painkiller.example.tld (Moe Trin) writes:
    > 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.

    > It dawns on me that
    > chat is talking to stdio, and pppd is redirecting the I/O.


    Yes.

    > 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.

    --
    James Carlson, KISS Network
    Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084
    MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677

+ Reply to Thread