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