On Sat, Sep 08, 2001 at 10:28:16AM -0500, D J Hawkey Jr wrote:
> On Sep 08, at 06:15 PM, Peter Pentchev wrote:
> >
> > On Sat, Sep 08, 2001 at 07:44:45AM -0500, D J Hawkey Jr wrote:
> > > On Sep 08, at 02:32 PM, Alexander Langer wrote:
> > > >
> > > > Thus spake D J Hawkey Jr (hawkeydvisi.com):
> > > >
> > > > > > This still lets you load own kernel modules.
> > > > >
> > > > > Not if you blow away the /modules directory (note that I haven't tried
> > > > > this).
> > > >
> > > > /me hands Dave a decent C compiler and some C h0h0magic.
> > >
> > > I didn't write "build the kernel without it".
> > >
> > > As I wrote, I hadn't tried it. I take it one cannot remove that tree,
> > > even after seeing that the kernel doesn't need it? I'm meaning run-time
> > > here, not build-time.
> >
> > I believe that what Alex meant is that you can simulate kldload(8)'s
> > functionality in a little C program of your own. Even more than that,
> > kldload(8) itself allows you to specify a full path to a module,
> > not just a filename, so even if you blow away the /modules directory,
> > J. Random Luser can still 'kldload /var/tmp/rkit.kld'.
> >
> > Yes, you can remove /modules; no, that does not gain you any safety.
>
> Kris addressed this, too, and yes, you're both right.
>
> Q: Can the kernel be "forced" to load a module from within itself? That
> is, does a cracker need to be in userland?

Yes, certainly; all kldload(8) does is invoke the kldload(2) syscall,
nothing more, nothing userspace-magical.
All a kernel routine needs to do is either invoke that syscall, or
call the internal kernel functions that kldload(2) calls, like e.g.
linker_find_file_by_name() and linker_load_file() in sys/kern/kern_linker.c

G'luck,
Peter

-- 
This sentence would be seven words long if it were six words shorter.
To Unsubscribe: send mail to majordomoFreeBSD.org
with "unsubscribe freebsd-security" in the body of the message

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]