The disappearing sys_call_table export.
It seems like nobody belives that there are any technically valid reasons for hooking system calls, but how should e.g anti virus on-access scanners intercept syscalls?
Preloading libraries, ptracing init, patching g/libc, etc. are obviously not the way to go.
-p.
Quoted 5 lines · petter wahlman
It seems like nobody belives that there are any technically valid
reasons for hooking system calls, but how should e.g anti virus on-access scanners intercept syscalls?
Preloading libraries, ptracing init, patching g/libc, etc. are obviously not the way to go.
those obviously need to be implemented via the security subsystem (eg LSM). Hooks are obviously the wrong level to do things and I could even tell you that you cannot implement this right from a module actually.
Quoted 5 lines · petter wahlman
It seems like nobody belives that there are any technically valid reasons for hooking system calls, but how should e.g anti virus on-access scanners intercept syscalls?
Preloading libraries, ptracing init, patching g/libc, etc. are
^^^^^^^^^^^^^^^^^^^
|________ Is the way to go. That's how
you communicate every system-call to a user-mode daemon that does whatever you want it to do, including phoning the National Security Administrator if that's the policy.
Quoted 2 lines
obviously not the way to go.
Oviously wrong.
Also, there are existing system calls that are not in use. You can modify your copy of a kernel for whatever you want. Example system calls that simply return -ENOSYS are break, stty, gtty, prof, acct, lock, and mpx. That should be enough entry-points to muck with.
Cheers,
Dick Johnson
Penguin : Linux version 2.4.20 on an i686 machine (797.90 BogoMips). Why is the government concerned about the lunatic fringe? Think about it.
Quoted 9 lines · Richard B. Johnson
Quoted 5 lines · petter wahlman
It seems like nobody belives that there are any technically valid reasons for hooking system calls, but how should e.g anti virus on-access scanners intercept syscalls?
Preloading libraries, ptracing init, patching g/libc, etc. are^^^^^^^^^^^^^^^^^^^
|________ Is the way to go. That's how
Quoted 8 lines
you communicate every system-call to a user-mode daemon that does whatever you want it to do, including phoning the National Security Administrator if that's the policy.
Quoted 2 lines
obviously not the way to go.
Oviously wrong.
And how would you force the virus to preload this library?
-p.
Quoted 17 lines · petter wahlman
Quoted 16 lines · Richard B. Johnson
Quoted 5 lines · petter wahlman
It seems like nobody belives that there are any technically valid reasons for hooking system calls, but how should e.g anti virus on-access scanners intercept syscalls?
Preloading libraries, ptracing init, patching g/libc, etc. are^^^^^^^^^^^^^^^^^^^
|________ Is the way to go. That's howyou communicate every system-call to a user-mode daemon that does whatever you want it to do, including phoning the National Security Administrator if that's the policy.
Quoted 2 lines
obviously not the way to go.
Quoted 7 lines
Quoted 1 line
Oviously wrong.
And how would you force the virus to preload this library?
-p.
I wouldn't.
Cheers,
Dick Johnson
Penguin : Linux version 2.4.20 on an i686 machine (797.90 BogoMips). Why is the government concerned about the lunatic fringe? Think about it.
Quoted 17 lines · petter wahlman
Quoted 16 lines · Richard B. Johnson
Quoted 5 lines · petter wahlman
It seems like nobody belives that there are any technically valid reasons for hooking system calls, but how should e.g anti virus on-access scanners intercept syscalls?
Preloading libraries, ptracing init, patching g/libc, etc. are^^^^^^^^^^^^^^^^^^^
|________ Is the way to go. That's howyou communicate every system-call to a user-mode daemon that does whatever you want it to do, including phoning the National Security Administrator if that's the policy.
Quoted 2 lines
obviously not the way to go.
Quoted 7 lines
Quoted 1 line
Oviously wrong.
And how would you force the virus to preload this library?
-p.
The same way you would force a virus to not be statically linked. You make sure that only programs that interface with the kernel thorugh your hooks can run on that particular system.
Cheers,
Dick Johnson
Penguin : Linux version 2.4.20 on an i686 machine (797.90 BogoMips). Why is the government concerned about the lunatic fringe? Think about it.
Quoted 22 lines · Richard B. Johnson
Quoted 20 lines · petter wahlman
Quoted 17 lines · Richard B. Johnson
Quoted 5 lines · petter wahlman
It seems like nobody belives that there are any technically valid reasons for hooking system calls, but how should e.g anti virus on-access scanners intercept syscalls?
Preloading libraries, ptracing init, patching g/libc, etc. are^^^^^^^^^^^^^^^^^^^
|________ Is the way to go. That's howyou communicate every system-call to a user-mode daemon that does whatever you want it to do, including phoning the National Security Administrator if that's the policy.
Quoted 2 lines
obviously not the way to go.
Oviously wrong.
Quoted 9 lines
Quoted 4 lines
And how would you force the virus to preload this library?
-p.
The same way you would force a virus to not be statically linked. You make sure that only programs that interface with the kernel thorugh your hooks can run on that particular system.
Can you please elaborate.
How would you implement the access control without modifying the respective syscalls or the system_call(), and would you'r solution be possible to implement run time?
Regards,
-p.
Quoted 33 lines · petter wahlman
Quoted 22 lines · Richard B. Johnson
Quoted 20 lines · petter wahlman
Quoted 17 lines · Richard B. Johnson
Quoted 5 lines · petter wahlman
It seems like nobody belives that there are any technically valid reasons for hooking system calls, but how should e.g anti virus on-access scanners intercept syscalls?
Preloading libraries, ptracing init, patching g/libc, etc. are^^^^^^^^^^^^^^^^^^^
|________ Is the way to go. That's howyou communicate every system-call to a user-mode daemon that does whatever you want it to do, including phoning the National Security Administrator if that's the policy.
Quoted 2 lines
obviously not the way to go.
Oviously wrong.
Quoted 9 lines
Quoted 4 lines
And how would you force the virus to preload this library?
-p.
The same way you would force a virus to not be statically linked. You make sure that only programs that interface with the kernel thorugh your hooks can run on that particular system.
Quoted 7 lines
Can you please elaborate.
How would you implement the access control without modifying the respective syscalls or thesystem_call(), and would you'r solution be possible to implement run time?Regards,
The program loader for shared-library programs is ld.so or ld-linux.so. It's the thing that mmaps the shared libraries and, eventually calls _start: in the beginning of the program:
execve("/bin/ps", ["ps"], [/* 32 vars */]) = 0
brk(0) = 0x804c748open("/etc/ld.so.preload", O_RDONLY) = 3 <<<<<<--- your hooks here!!fstat(3, {st_mode=S_IFREG|0644, st_size=0, ...}) = 0 old_mmap(NULL, 0, PROT_READ|PROT_WRITE, MAP_PRIVATE, 3, 0) = 0
close(3) = 0
Cheers,
Dick Johnson
Penguin : Linux version 2.4.20 on an i686 machine (797.90 BogoMips). Why is the government concerned about the lunatic fringe? Think about it.
Quoted 47 lines · Richard B. Johnson
Quoted 33 lines · petter wahlman
Quoted 22 lines · Richard B. Johnson
Quoted 20 lines · petter wahlman
Quoted 17 lines · Richard B. Johnson
Quoted 5 lines · petter wahlman
It seems like nobody belives that there are any technically valid reasons for hooking system calls, but how should e.g anti virus on-access scanners intercept syscalls?
Preloading libraries, ptracing init, patching g/libc, etc. are^^^^^^^^^^^^^^^^^^^
|________ Is the way to go. That's howyou communicate every system-call to a user-mode daemon that does whatever you want it to do, including phoning the National Security Administrator if that's the policy.
Quoted 2 lines
obviously not the way to go.
Oviously wrong.
Quoted 9 lines
Quoted 4 lines
And how would you force the virus to preload this library?
-p.
The same way you would force a virus to not be statically linked. You make sure that only programs that interface with the kernel thorugh your hooks can run on that particular system.
Quoted 7 lines
Can you please elaborate.
How would you implement the access control without modifying the respective syscalls or thesystem_call(), and would you'r solution be possible to implement run time?Regards,
The program loader for shared-library programs is ld.so or ld-linux.so. It's the thing that mmaps the shared libraries and, eventually calls
_start: in the beginning of the program:
Quoted 7 lines
execve("/bin/ps", ["ps"], [/* 32 vars */])= 0
brk(0) =0x804c748open("/etc/ld.so.preload", O_RDONLY)= 3 <<<<<<--- your hooks here!!fstat(3, {st_mode=S_IFREG|0644, st_size=0, ...})= 0old_mmap(NULL, 0, PROT_READ|PROT_WRITE, MAP_PRIVATE, 3, 0)= 0
close(3) = 0
That would work on dynamically linked executables, but how do you control access to file shares or static executables.? Denying access to the latter would even prevent ldconfig from running.
Regards,
-p.
Quoted 56 lines · petter wahlman
Quoted 47 lines · Richard B. Johnson
Quoted 33 lines · petter wahlman
Quoted 22 lines · Richard B. Johnson
Quoted 20 lines · petter wahlman
Quoted 17 lines · Richard B. Johnson
Quoted 5 lines · petter wahlman
It seems like nobody belives that there are any technically valid reasons for hooking system calls, but how should e.g anti virus on-access scanners intercept syscalls?
Preloading libraries, ptracing init, patching g/libc, etc. are^^^^^^^^^^^^^^^^^^^
|________ Is the way to go. That's howyou communicate every system-call to a user-mode daemon that does whatever you want it to do, including phoning the National Security Administrator if that's the policy.
Quoted 2 lines
obviously not the way to go.
Oviously wrong.
Quoted 9 lines
Quoted 4 lines
And how would you force the virus to preload this library?
-p.
The same way you would force a virus to not be statically linked. You make sure that only programs that interface with the kernel thorugh your hooks can run on that particular system.
Quoted 7 lines
Can you please elaborate.
How would you implement the access control without modifying the respective syscalls or thesystem_call(), and would you'r solution be possible to implement run time?Regards,
The program loader for shared-library programs is ld.so or ld-linux.so. It's the thing that mmaps the shared libraries and, eventually calls
_start: in the beginning of the program:Quoted 7 lines
execve("/bin/ps", ["ps"], [/* 32 vars */])= 0
brk(0) =0x804c748open("/etc/ld.so.preload", O_RDONLY)= 3 <<<<<<--- your hooks here!!fstat(3, {st_mode=S_IFREG|0644, st_size=0, ...})= 0old_mmap(NULL, 0, PROT_READ|PROT_WRITE, MAP_PRIVATE, 3, 0)= 0
close(3) = 0
Quoted 5 lines
That would work on dynamically linked executables, but how do you control access to file shares or static executables.? Denying access to the latter would even prevent ldconfig from running.
You can execute existing static-linked files by having ld.so execute them. Ld.so "knows" how to execute static-linked files. You just need to change kernel code to include the static executable magic number with the dynamic linked magic number as requiring the preprocessing of the dynamic linker.
The only problem is that 'init' won't start if that loader isn't available. This not a problem for working systems. It's just a problem for broken ones. You use an unpatched kernel for maintenance.
Cheers,
Dick Johnson
Penguin : Linux version 2.4.20 on an i686 machine (797.90 BogoMips). Why is the government concerned about the lunatic fringe? Think about it.
Quoted 2 lines · petter wahlman
On Wed, 2003-05-07 at 18:59, Richard B. Johnson wrote:
[snip]
Quoted 8 lines
Quoted 3 lines
The same way you would force a virus to not be statically linked. You make sure that only programs that interface with the kernel thorugh your hooks can run on that particular system.
Can you please elaborate.
How would you implement the access control without modifying the respective syscalls or thesystem_call(), and would you'r solution be possible to implement run time?
Access control is available via the LSM, with well defined interfaces. If that is what you want to control, then use the LSM, and not the syscall table.
Quoted 15 lines · petter wahlman
Quoted 14 lines · Richard B. Johnson
Quoted 4 lines · petter wahlman
It seems like nobody belives that there are any technically valid reasons for hooking system calls, but how should e.g anti virus on-access scanners intercept syscalls?
Preloading libraries, ptracing init, patching g/libc, etc. are^^^^^^^^^^^^^^^^^^^
|________ Is the way to go. That's howyou communicate every system-call to a user-mode daemon that does whatever you want it to do, including phoning the National Security Administrator if that's the policy.
Quoted 5 lines
Quoted 3 lines
Quoted 1 line
obviously not the way to go.
Oviously wrong.
And how would you force the virus to preload this library?
You don't have to... The preload is performed by the program image loader, before the virus, or even the application, can be started.
You don't really want to do it anyway... Consider a file open (like tar)... you gonna try to scan the entire archive for a virus????
Quoted 7 lines · petter wahlman
It seems like nobody belives that there are any technically valid reasons for hooking system calls, but how should e.g anti virus on-access scanners intercept syscalls?
Preloading libraries, ptracing init, patching g/libc, etc. are obviously not the way to go.
Well, for a system wide system call hook, a kernel mechanism is necessary (and useful too IMHO). However for our usage (MPI) it is enough to know when the current process calls either sbrk(-n) or munmap glibc functions, thus it is sufficient to implement some kind of callback functionality for certain glibc functions, sort of like the malloc/free hooks but on a more general basis since some applications doesn't use malloc/free but implement their own alloc/free algorithms using the syscalls (one example is f90 apps).
Ideas anyone ?
Regards,
Signature · 4 lines
Steffen Persvold | Scali AS mailto:[email protected] | http://www.scali.com Tel: (+47) 2262 8950 | Olaf Helsets vei 6 Fax: (+47) 2262 8951 | N0621 Oslo, NORWAY
Quoted 19 lines · Steffen Persvold
Quoted 7 lines · petter wahlman
It seems like nobody belives that there are any technically valid reasons for hooking system calls, but how should e.g anti virus on-access scanners intercept syscalls?
Preloading libraries, ptracing init, patching g/libc, etc. are obviously not the way to go.Well, for a system wide system call hook, a kernel mechanism is necessary (and useful too IMHO). However for our usage (MPI) it is enough to know when the current process calls either sbrk(-n) or munmap glibc functions, thus it is sufficient to implement some kind of callback functionality for certain glibc functions, sort of like the malloc/free hooks but on a more general basis since some applications doesn't use malloc/free but implement their own alloc/free algorithms using the syscalls (one example is f90 apps).
Quoted 1 line
Ideas anyone ?
I think the complete list of functions to be hooked needs to be at least:mmap(MAP_FIXED), munmap, sbrk(-n), shmat, shdt. The mapping cases are needed because a mmap(MAP_FIXED) can implicitly unmap an area under them, before the new address is used.
This is not a kernel issue as this is purely a user space problem, the kernel provides all of the necessary functionality.
I suspect what is needed is something like:
int on_unmap(void (*func)(void *start, size_t length, void *), void *arg);
With the function called before the unmap actually occurs, that way the multi thread case is safe. It needs to be built so that multiple libraries can cooperate cleanly.
Ulrich what do you think. Is the above function reasonable? Something like it is needed to manage caches of pinned memory for high performance kernel bypass libraries.
Eric