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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED], > > 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.).
