On Sat, 17 Jul 2010 15:51:06 +0800, supercodeing35271 supercodeing35271 said: > Hi,i am now write a simple file comparison and protect program in > linux kernel module using the way of intercepting the syscall.What i You should probably be using the LSM security exits to do this work instead of intercepting the system call yourself. Somebody else has already done the hard work, all you have to do is write the actual security code. This may not seem like a lot when you're just trying to intercept sys_mkdir(), but you'll quickly discover that doing a *real* security module will end up requiring the mediation of at least 30 to 40 system calls, if not more. > have done is that when the module insmod into kernel,i can appoint a > path that make any action which intend to mkdir in the path return a > fail,so the path can be protect against malicious tamper. You'll need to protect more than just mkdir - there's also directory renames (move the name to an unprotected name, screw with it, move it back), hard links to files inside the directory, etc etc etc. > So my question is that is any idea of identify the shell command like > mkdir if it is a absolute path or not,and how to change relative path > into absolute for my module can intercept the relative path No. The problem you're trying to solve is "given an inode, find the original pathname", and it simply can't be done, because a file can have more than one name. Consider this: mkdir /tmp/a # your protected pathname mkdir /tmp/b touch /tmp/a/foo # your protected file ln /tmp/a/foo /tmp/b/bar # Oh shit Now if the attacker opens that inode, which of those two pathnames should we return? It's possible to walk backwards across each dentry/inode in the file path and recover *A* filename, but that's not good enough for security purposes because it's not a guaranteed canonical name. In the example above, you'll get back /tmp/b/bar because that's the name it was opened under - which is exactly the answer you *don't* want to get back because it will bypass your security. It's things like that why SELinux does inode labeling instead of filename based security. To be fair, inode labeling has its own issues - in particular, it's difficult to securely create a file with a security context different than its parent directory, so you end up needing warts like 'restorecond'. If you want to do pathname-based security, you should probably look at the Smack or Tomoyo LSMs, both of which are already in-kernel for quite some time, and see how they do things.
Attachment:
pgpgWJHyZpwgI.pgp
Description: PGP signature
_______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/