Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 25 Oct 2002 20:57:03 -0700
From:      "Maksim Yevmenkin" <Maksim.Yevmenkin@exodus.net>
To:        "Terry Lambert" <tlambert2@mindspring.com>, "Brooks Davis" <brooks@one-eyed-alien.net>
Cc:        "Bakul Shah" <bakul@bitblocks.com>, <freebsd-current@FreeBSD.ORG>
Subject:   RE: pppd not working on latest current 2002-10-20
Message-ID:  <45258A4365C6B24A9832BFE224837D552B125C@sjdcex01.int.exodus.net>

next in thread | raw e-mail | index | archive | help

> From:	Terry Lambert [mailto:tlambert2@mindspring.com]
>
> > Brooks Davis wrote:
> > This isn't going to have an effect on the ability to use kernel ppp =
for
> > other things.  The tty orientation of pppd and the outdated, =
unmodular
> > design on ppp(4) have taken care of that.  This patch gives people
> > the functionality they want (pppd just working) without any major
> > entanglements (the whole function is <20 lines).  If someone
> > wants to make pppd work on arbitrary devices we can deal with that =
when
> > it happens and I frankly doubt it's ever going to since we've got
> > netgraph to do that with.

> Depending on the value of "sysctl kern.module_path", if the "if_ppp"
> module does not exist, and one of the path components is writeable,
> then this would permit you to abuse the pppd to load arbitrary modules
> into the kernel.
>=20
> So I understand Bakul's complaint.
>=20
> But by the same token, "mount" and "ifconfig" have the same problems;
> on the other hand, unlike pppd, they are not suid root.
>=20
> On general principles, loading modules with commands, rather than the
> kernel doing it automatically, is a bad idea.  But FreeBSD already
> does this in a number of commands, because it lacks a certralized
> "feature demand" support facility.

i'm sorry for jumping in the middle of the thread, but long time
ago i wrote something called kerneld. it is still available on
SourceForge (http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/kerneld/)

the idea was very simple:

1) create a char device "kd"
2) add hooks inside kernel, so whenever filesystem, interface or
   char device is requested but not present send message to the
   "kd" device.
3) user space daemon that listens on /dev/kd for the events and
   loads appropriate module (as configured)

i send RFC email to -hackers, but i got so many negative replies
so i dropped the whole idea :)

> You could also make security arguments on the basis of "what if the
> administrator didn't want the machine to be able to be configured
> for PPP -- on purpose?"

yes. i got the similar arguments: "i do not want any smart-ass
daemon load and unload modules. i want to do it myself"

> As long as you control the module path, I don't think this is a real
> risk.  There is such a thing as being too paranoid.
>
> As it is, this patch does nothing worse than add to an existing
> mess brought about by not having an integrated demand-load facility;
> I don't see this as a problem... if there;s a problem, fix it first
> in mount and ifconfig, before you complain about this patch.

thanks,
max



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?45258A4365C6B24A9832BFE224837D552B125C>