From owner-freebsd-arch Sun Jul 9 6:26:38 2000 Delivered-To: freebsd-arch@freebsd.org Received: from turtle.looksharp.net (cc360882-a.strhg1.mi.home.com [24.2.221.22]) by hub.freebsd.org (Postfix) with ESMTP id E775C37B7A5 for ; Sun, 9 Jul 2000 06:26:28 -0700 (PDT) (envelope-from bsdx@looksharp.net) Received: from localhost (bsdx@localhost) by turtle.looksharp.net (8.9.3/8.9.3) with ESMTP id JAA27390; Sun, 9 Jul 2000 09:26:20 -0400 (EDT) (envelope-from bsdx@looksharp.net) Date: Sun, 9 Jul 2000 09:26:20 -0400 (EDT) From: Adam To: Alfred Perlstein Cc: arch@FreeBSD.ORG Subject: Re: making the snoop device loadable. In-Reply-To: <20000709033329.N25571@fw.wintelcom.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sun, 9 Jul 2000, Alfred Perlstein wrote: >* Adam [000709 01:20] wrote: >> On Sun, 9 Jul 2000, Alfred Perlstein wrote: >> >> >Ok, I noticed that with a bit of hacking the snp device can be made >> >loadable. Making it unloadable is a bit of a pain, but I can >> >implement it using refcounting on the amount of ttys that have snp >> >devices hooked onto them so that the machine doesn't panic if you >> >unload it. >> > >> >The 'problem' that happens is that kern/tty.c now needs to include >> >snoop.h unconditionally, and it also has to provide some exernally >> >visible pointers to functions for the loadable snoop device to >> >hook into. >> > >> >Basically, does anyone have a problem with snp becoming loadable >> >before I commit to finishing off the work? (it's loadable now, but >> >not unloadable). >> >> Would it make sense to have a kernel option or something to disable this >> feature without using securelevels? I'm thinking of the situation of the >> owner of a computer is paranoid (or highly ethical) and strongly dislikes >> the snooping ability yet other root users on the machine might not have >> the same standards and try to sneak in a module to peek around quick or >> cause trouble with other users. As it is now you would have to cause >> quite a commotion by at least rebooting the machine... > >This is security through irritation, a well crafted kernel module >could upsurp the tty subsystem and make snooping possible anyway. > >If you don't want it loadable (or possible) then you must raise >securelevel. > >My initial implementation seemed to work just by loading the module, >which was very strange considering that several calls into the snoop >module weren't being made. It could have been a lack of sleep and >I imagined this 'feature', but it's possible. There are alot of people who have root that couldn't craft such a kernel module if they wanted to, and even if they could, I'd venture to say they'd need a whole bunch of motivation and a considerable amount of time. I cannot tell from the init manpage which securelevel is needed to prevent loading kernel modules but I'm pretty sure it would make things a pain in the butt for admins trying to do Real Work remotely such as upgrading the kernel. I think it would be nice to prevent easy snooping without making life hard for the admin. The kernel has all the power over the computer, I dont think this is an issue that should require engineering to prevent, I would like my kernel to just say NO. If I have to hack it so the snoop module wouldnt work if loaded or something, thats a pain for me since I couldnt code hello world from a blank editor if I wanted to. If I had to tell someone else they had to hack the kernel to prevent this or have the kernel get alot more anal in general about permissions, I don't think it would go over well, especially to someone less experienced than me. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message