Re: DEVFSv50 and /dev/fb? (or /dev/fb/? ???)

Richard Gooch (rgooch@atnf.csiro.au)
Wed, 19 Aug 1998 16:34:13 +1000


Terry L. Ridder writes:
> Richard Gooch wrote:
> >
> > Raul Miller writes:
> > >
>
> <snip>
>
> > >
> > > Richard Gooch <Richard.Gooch@atnf.CSIRO.AU> wrote:
> > > > There could be similar potential security problems with ordinary
> > > > disc-based device nodes and kmod too, it would seem.
> > >
> > > Why? Device files have permissions on them.
> >
> > Hm. OK. That's something that I could do with devfsd. However, it
> > still seems to me that loading a driver should never compromise your
> > system. If it does the driver is broken.
> >
>
> In a perfect world that may be true, since however we live in an
> imperfect
> world, and we all make mistakes, security will probably continued to be
> compromised by drivers/daemons/etc. When a problem is discovered they
> are fixed. So yes in a perfect world a driver/daemon/etc should
> compromise
> a system, however in the imperfect world we live in they do.

Perhaps. As I said, this functionality (optional) could be easily
added to devfsd. Time for devfsd protocol revision 1 :-)

> > Well, I cover the reasons in the FAQ. One other reason I should get
> > around to adding: security. I expect many systems will not want to
> > change device permissions (the drivers provide sensible defaults). In
> > that case if some random hacker frobs the permissions on /dev/sda*
> > then the next reboot gives you back the default (safe) permissions.
>
> This to me seems like a really bad idea.
> Once a system has been compromised it would seem that you would
> want to keep as much "evidence" as possible. Resetting the
> permissions at the next reboot would be destroy some "evidence".
> This may also be the only piece of "evidence" that is readily visible.

This seems to be contrary to the accepted view by security people
which is to close of the holes *fast* and then worry about evidence. I
think the consensus is that "evidence" does not translate into
convictions (unless you are lucky and the cracker is in the same
state/country as you and has left other clues lying around).

Some approaches to security breaches are to *immediately* boot single
user and reinstall the OS from CD-ROM.

Regards,

Richard....

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.altern.org/andrebalsa/doc/lkml-faq.html