Hi, On Tue, 15 Feb 2000, elijah wright wrote: W>> communicates with the kernel using character device to send and receive W>> "packets". Daemon contains the whole logic and implements the concrete W>> security policy. That means, that medusa can (as opposite to another W>[...] W>> * ability to enforce process to execute an arbitrary code. This feature W>> is usefull to enforce logging drom that process and so. W> W>the fact that your program has both a userspace and a kernel-space W>component makes it almost immediately suspect as "vulnerable". kind of W>funny for me to get to reply to a "security tool" announcement with a W>notice-of-warning. I must complain. That's misleading: in-kernel part of ANY software can be as vulnerable as the user-space part. It's _software_ and software can contain bugs. No matter if it is all in kernel, all in userspace or divided into two parts, which communicate via some interface. Our user-space daemon comunicates only with _our_ well-defined kernel interface and you can build it as a static binary, if you wish. It can protect itself against deletion, rename or ptrace(). What kind of vulnerability do you suppose it to have? W>has the source to the userspace module been audited yet? hopefully by W>someoen other than the authors? Not yet. It's young, 0.x.x only. And this was the first "official" announce. Possibly you? Sources are freely available. W>that last part sounds like it might make, with a few mods, a great 3l33t W>h@x0r tool :) perhaps it might be most useful to someone good enough to W>get a rootshell but not good enough to hack away at the process table by W>themselves. it requires some modifications in kernel, which cannot be built as a module. I can hardly imagine such 'h@x0r' downloading the kernel source, installing medusa and recompiling on the target system without being caught. This feature was meant to do extra logging. Today we have many uses for it. For example, you can write config, which will enforce some piece of code on each unlink(). This code will re-write the file with 0s and FFs first, so you can be sure, that some young boy who learned how to use strings -a will not get your sensitive data even on successful crack. On the other side, one can make some code, which will copy files to some archive partition before deletion, thus ensuring that someone will not delete logs accidentally. And this may apply to /var/log only, for example. But to take it generally, you are right. We are using double-edged weapons here. As in the real life, they are more effective than the 'safe' ones. And of course, everything depends on the way you configure it. This is meant to provide some 'extra control' to experienced administrator, who have "safe" system and want to add an extra layer of security. W>all in all, this thing scares me. It scares me too :) for similiar reason: it's really powerful.. Now I have my TODO list full of example configs, which would be nice to do. I don't want this to become flame. This mail represents only my point of view and I may be wrong. Answer me privately please. Milan -- Milan Pikula, WWW. Finger me for Geek Code. http://fornax.elf.stuba.sk/~www, wwwat_private .. dajte mi pevnu linku a pohnem zemegulou ..
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 15:35:35 PDT