Re: Keeping track of called syscalls in real-time
> This sounds like an LSM, possibly with a component which communicates
> with userspace, depending on how sophisticated "verify" needs to be.
Yes, the component *should* communicate with the userspace. The
sophistication of "verify" varies from user to user. The tool will
provide a few procedures to, say, verify integrity and log call. But
"verify" was a plain example, where my point was that the user could
extend/add these procedures for their own needs.
VisorFlow sounds interesting. I've seen the paper is on submission. When
will it be published?
On 06/28/2017 09:49 PM, W. Michael Petullo wrote:
>> Whenever fopen("/etc/shadow", "r") is called, the tool would intercept
>> it, run the verify() procedure, and return back to the syscall, allowing
>> it to do it's job.
>
> This sounds like an LSM, possibly with a component which communicates
> with userspace, depending on how sophisticated "verify" needs to be.
>
> We've also done some very early work in trying to do this type of thing
> from a hypervisor. See:
>
> https://www.flyn.org/projects/VisorFlow/
>
--
- seds
~> https://seds.nl
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Keeping track of called syscalls in real-time
Let me clear things out.
> As I said before - knowing this, what do you *do* with it? Statistics
> after the fact? Apply security rules before the fact? Something else?
> The answer depends *a lot* on what you're planning to *do* with the info.
There is no statistics involved. I am trying to intercept *some* system
calls. The list of syscalls I should intercept will be set by the user
in a form of a rule, however, if a specified syscall is meant for file
I/O (i.e. fopen), the user would need to specify which files he would
like the interception to take part on whenever fopen is called.
A simple example of a user rule would be (in a nutshell):
# syscall #intercept #file_arg #action #onuid #oncall
fopen 1/etc/shadow verify12 0
Where #syscall specifies which syscall to intercept, #intercept is a
bool whenever it should run or not, the #file_arg basically says
"intercept fopen only when fopen is called on /etc/shadow", #action
specifies the name of the procedure the tool would run when intercepting
fopen, #onuid specifies the user uid to intercept (run this just on the
user who has 12 as uid) and finally, #oncall is a bool telling the tool
to intercept after the syscall has returned (1 for after the call, 0 for
before).
Whenever fopen("/etc/shadow", "r") is called, the tool would intercept
it, run the verify() procedure, and return back to the syscall, allowing
it to do it's job.
> Yes, but the question is "what value of "I then receive" appropriate?
> Do you need it before the syscall is executed? After it is finished?
> Or "don't care at all as long as we eventually get a complete trail"?
That all depends on the config for *that* specific call. Using the
previous examples, I would need the kernel to tell me right when fopen
was called;
int foo(...){
...
fopen(arg, "r"); <- need an alert from the kernel here
}
I am using the word "tool" here, but I am willing to get this builtin to
the kernel when compiling it, so as a root user, it would be slightly
more difficult to disable it without having to recompile everything (afaik).
> Congrats - you just re-invented the LSM subsystem. Or possibly seccomp,
> depending on what it is you're trying to accomplish.
>
> Note that LSM's have some restrictions on what they can and can't do,
> mostly because it's otherwise almost impossible to do any reasoning about
> the security and stability guarantees of a process/system otherwise.
I understand seccomp and LSM allows __some__ type of syscall
interposition (where afaik seccomp blocks mostly all of them), but what
I am willing to do here is not *reinvent* the wheel, I am willing to
make things a bit more configurable, where a user has access to an API
where he could write custom procedures to run on the interception side,
without having to dig through the source.
Many thanks
On 06/28/2017 07:26 PM, valdis.kletni...@vt.edu wrote:
> On Wed, 28 Jun 2017 19:06:56 -0300, Ben Mezger said:
>> I'm actually formulating my thesis project. I am looking for a way to
>> intercept system calls (those chosen by the users), where I can keep
>> track of what syscall has been called and by who.
>
> As I said before - knowing this, what do you *do* with it? Statistics
> after the fact? Apply security rules before the fact? Something else?
> The answer depends *a lot* on what you're planning to *do* with the info.
>
>> A big picture of the _main_ idea of interception would be: Application
>> called a syscall -> Intercept and delay call -> do something before the
>> call -> return back to the syscall.
>
> "Do something before the syscall".
>
> Congrats - you just re-invented the LSM subsystem. Or possibly seccomp,
> depending on what it is you're trying to accomplish.
>
> Note that LSM's have some restrictions on what they can and can't do,
> mostly because it's otherwise almost impossible to do any reasoning about
> the security and stability guarantees of a process/system otherwise.
>
>> By real-time I mean as soon as an application called a syscall (i.e.
>> fopen), I could then receive a reply from the kernel informing me X
>> called fopen, where X could be a pid or whatever.
>
> Yes, but the question is "what value of "I then receive" appropriate?
> Do you need it before the syscall is executed? After it is finished?
> Or "don't care at all as long as we eventually get a complete trail"?
>
>>>> Have you looked at the syscall audit facility?
>>
>> I have not. Are you talking about auditctl?
>
> That's part of the userspace utilities that interface to the audit system.
>
--
- seds
~> https://seds.nl
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Keeping track of called syscalls in real-time
I'm actually formulating my thesis project. I am looking for a way to intercept system calls (those chosen by the users), where I can keep track of what syscall has been called and by who. A big picture of the _main_ idea of interception would be: Application called a syscall -> Intercept and delay call -> do something before the call -> return back to the syscall. By real-time I mean as soon as an application called a syscall (i.e. fopen), I could then receive a reply from the kernel informing me X called fopen, where X could be a pid or whatever. >> Have you looked at the syscall audit facility? I have not. Are you talking about auditctl? On 06/28/2017 06:19 PM, valdis.kletni...@vt.edu wrote: > On Wed, 28 Jun 2017 17:48:15 -0300, Ben Mezger said: >> Can the kernel keep track of all the system calls that were called by an >> application/module in real-time? >> I know I can statically use strace, or even gdb, but I am looking for a >> solution in real time when the application/module is already running and >> the user has no control over it. > > What actual problem are you trying to solve by having the information? > > How "real-time" does it have to be? > > Have you looked at the syscall audit facility? > > > > ___ > Kernelnewbies mailing list > Kernelnewbies@kernelnewbies.org > https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies > -- - seds ~> https://seds.nl ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Keeping track of called syscalls in real-time
Can the kernel keep track of all the system calls that were called by an application/module in real-time? I know I can statically use strace, or even gdb, but I am looking for a solution in real time when the application/module is already running and the user has no control over it. I am not sure if a system call needs to go through a sort of wrapper to get it from the syscall table, which I'm then assuming I can get such info from there, but I am not sure. I am looking for hints/options to archive this. Many thanks -- - seds ~> https://seds.nl ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Qemu+busybox for kernel development
The way I do it is by compiling the kernel as I would normaly do for a real system. Then, after copying vmlinuz and generating my initramfs, I run Qemu: $ qemu-system-x86_64 -kernel vmlinuz -initrd initramfs.img -append param1=value1 For me, as I am mostly testing, there is no need for a full-feature root FS, since initramfs is perfect for containing small test application and loadable kernel modules. This might come in hand, though: https://lwn.net/Articles/660404/ On 06/28/2017 05:46 AM, Alexander Kapshuk wrote: > I am trying to setup a build environment where I can run the kernel and > see how the changes I have made to the kernel source work. > My understanding, based on googling, is that it is common practice in > the kernel community to use a virtualised environment for that purpose. > What I have done so far is create a ramfs that is built into the kernel, > as described here [1] and here [2]. > > [1] https://landley.net/writing/rootfs-howto.html > [2] > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/plain/Documentation/early-userspace/README?h=v4.12-rc7 > > a). I have generated a minimal initramfs_list file: > scripts/gen_initramfs_list.sh -d >usr/initramfs_list > Which looks like this: > # This is a very simple, default initramfs > > dir /dev 0755 0 0 > nod /dev/console 0600 0 0 c 5 1 > dir /root 0700 0 0 > # file /kinit usr/kinit/kinit 0755 0 0 > # slink /init kinit 0755 0 0 > slink /bin/sh busybox 777 0 0 > file /init /bin/busybox 755 0 0 > > b). Set CONFIG_INITRAMFS_SOURCE: > CONFIG_INITRAMFS_SOURCE="/home/sasha/linux/usr/initramfs_list" > > c). And had the kernel generate the initramfs image: > make > ... > GEN usr/initramfs_data.cpio.gz > CHK include/generated/compile.h > AS usr/initramfs_data.o > LD usr/built-in.o > ... > > When I run the kernel in qemu I get an error message which complains > about /etc/init.d/rcS missing. > The posts online seem to suggest that this has got to do with the > busybox configuration. > So far, I have not been able to get my head around this problem. > Any points or suggestions would be much appreciated. > > Alexander Kapshuk. > > > > ___ > Kernelnewbies mailing list > Kernelnewbies@kernelnewbies.org > https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies > -- - seds ~> https://seds.nl ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
