[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Emergency Unmount...
On Wed, Apr 04, 2001 at 02:30:26PM +0200, Perego Paolo wrote:
> On Wed, Apr 04, 2001 at 01:30:38PM +0200, Erik Mouw wrote:
> > Hmm, security through obscurity has never been a good idea, and it's
> The point is that root needs a password to put MOD_USE_COUNT to 0 ( echoing
> that in a char dev ) and he needs to re-enter the password the same way, if he
> wants cleanup-module to exit fairly. I would prevent a malicious user puts
> MOD_USE_COUNT to 0 using /dev/kmem and then removing the module.
My point is that a malicious user can do that anyway. No amount of
"protection" in your module will prevent him. On way would be to remove
the module by manipulating /dev/kmem, another way would be to replace
the password in the module by another one (again using /dev/kmem) so
the module can be removed by normal use of rmmod.
> I can't figure out what do you means talking about obscurity :)
Obscure (and/or undocumented) ways to protect a system are not going to
work, only openly peer reviewed protection schemes do. For examples,
look at DVD CSS, GSM encryption, DES, and the many broken protection
schemes on the BugTraq mailing list.
> > quite easy to work around your "protection" scheme. Once I gain root
> I know it. However it's just my thesis work, some lacks are allowed aren't
> there? :)
I don't know, depends on your goal. If it is to protect the system
against malicious users, you should look at the root of the problems:
how to prevent normal users to gain root priviliges _at_ _all_. Any
kernel mechanism to protect root against himself is fundamentally
flawed, and my first question at your thesis defence would be how you
want to protect root against himself.
If you want to go the "password against rmmod way", be sure to document
in your thesis what the disadvantages of your approach are and why you
think your approach is right in this particular case.
> > Have a look at the MAGIC_SYSRQ code which does exactly what you want
> > (alt-sysrq-u).
> Already done. The point is that go_sync function ( linux/drivers/char/sysrq.c
> ) is not exported as symbol. I can't rip off that code because it referes to
> other symbols not exported by the kernel.
I think you can do it very simple by using the exported function
handle_sysrq():
sysrq_enabled = 1;
handle_sysrq('s', NULL, NULL, NULL);
handle_sysrq('u', NULL, NULL, NULL);
handle_sysrq('b', NULL, NULL, NULL);
Erik
--
J.A.K. (Erik) Mouw, Information and Communication Theory Group, Department
of Electrical Engineering, Faculty of Information Technology and Systems,
Delft University of Technology, PO BOX 5031, 2600 GA Delft, The Netherlands
Phone: +31-15-2783635 Fax: +31-15-2781843 Email: J.A.K.Mouw@its.tudelft.nl
WWW: http://www-ict.its.tudelft.nl/~erik/
-
Kernelnewbies: Help each other learn about the Linux kernel.
Archive: http://mail.nl.linux.org/
IRC Channel: irc.openprojects.net / #kernelnewbies
Web Page: http://www.surriel.com/kernelnewbies.shtml