Bug#126406: KPPP fixes, derived from #126406
Hello,
A bunch of us are struggling with the issue of how to make KPPP work for
users with a minimum of configuration. One stumbling block is the need
for the "noauth" option to be set for KPPP to establish most connections.
Currently, we instruct the users to edit /etc/ppp/options and change
"auth" to "noauth", but this is less than ideal, both because it requires
user intervention and from a security standpoint.
One alternative, that was suggested, was that KPPP ship the
file /etc/ppp/peers/kppp-options, which would only contain the string
"noauth". When kppp was executed, it would add "call kppp-options" to the
pppd arguments. Thus no one would have to edit /etc/ppp/options. It's
been pointed out that this isn't really secure either, since any member
of the dip group could then "call kppp-options" and use pppd with noauth.
Other than perhaps having "noauth" in /etc/ppp/peers/kppp-options
commented out by default, do you know of any way that KPPP could run with
the noauth option, that wouldn't require the editing of /etc/ppp/options
or be horribly insecure?
Any help or insight would be really appreciated. CC to
126406@bugs.debian.org.
Thanks,
Christopher Martin
On May 5, 2004 15:37, Achim Bohnet wrote:
> On Wednesday 05 May 2004 19:59, Christopher Martin wrote:
> > Hello,
> >
> > To deal with the problems users are having configuring KPPP, I've put
> > together some small patches (based on the ideas, not my own,
> > discussed in Bug #126406) that should resolve these issues. The
> > patches are attached to the e-mail I sent to 126406@bugs.debian.org,
> > which for some reason hasn't been CCed to debian-qt-kde.
>
> Great! Thx Christopher. FWIW I had a look at the patches and
> AFAICS it looks okay. Just one security note (sorry, no modem
> access to test):
>
> AFAIR you can use pppd with several call options.
> pppd call x call y ...
> This means everyone in dip group can now add noauth via
> call kppp-options to pppd.
>
> So in principle a bad member of the dip group could start
> a listening pppd daemon that allows dialup access without
> authorization (without noauth one needs edit
> pap,chap-secrets or add noauth in options or peers/*
> That can only be done by root. So it weakens security.
>
> If this scenario is not too paranoid I would say
> ship kppp-options with noauth commented out and document
> in README how to enable it (or maybe even add a dialog
> to kppp to warn about it). Grmbl, I really hope it's
> not necessary ;)
>
> Maybe one should ask/cc/fwd pppd maintainer before applying to
> kdenetwork pkgs?
>
> > There are two distinct problems. KPPP must be SUID root, in order for
> > PAP and/or CHAP authentication to work, given the way KPPP operates.
> > This is unavoidable (it creates and moves files around in /etc/ppp).
> > I've set kppp to be 4754 root.dip (the same permissions as pppd), so
> > membership in the dip group is still needed to execute kppp.
> >
> > Even when SUID, however, the custom pppd argument "noauth" doesn't
> > actually seem to have an effect, for some odd reason, and setting
> > "noauth" is necessary. Since having users edit /etc/ppp/options is
> > bad and cumbersome, I've added a work-around,
> > /etc/ppp/peers/kppp-options, which contains the string "noauth", and
> > which is used by giving kppp the default custom pppd argument "call
> > kppp-options". When done this way, the noauth option actually takes
> > effect.
> >
> > Also, I've elevated ppp from a Recommends to a dependency, since many
> > (most? all?) dial-up connections will need it, and this keeps things
> > easy and simple for users. Finally, I've removed the segment of
> > documentation which instructed users to modify /etc/ppp/options.
> >
> > With these changes, KPPP should "just work" without any mucking
> > around whatsoever, except for configuration of the modem itself
> > (symlinks, dev node creation if necessary, etc.).
Reply to: