Re: who know about this--can not catch the absolute path on intercept the mkdir() syscall in linux.

[Valdis.Kletnieks () vt edu]

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: _bin
Description:

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/