Re: Keeping track of called syscalls in real-time
> 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/
--
Mike
:wq
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Question about uprobes
>> I am writing some software that monitors a guest VM using virtual-machine >> introspection and "hijacks" system calls under certain conditions. For >> example, the program might inject an int3/breakpoint into the guest >> kernel at the entry point to sys_open. When the breakpoint is hit, the >> program might set the guest instruction pointer to the address to which >> sys_open would have itself returned and set register RAX to some desired >> error-code return value. >> >> The problem I am encountering is that for some reason the process is >> triggering a "uprobe ... failed to handle uretprobe" message from the >> guest kernel. I do not yet know enough about uprobes to understand what >> might be causing this. Is there something in procedures such as sys_open >> which must execute to prevent the error which causes the kernel to print >> this message? >> What vm hypervisor do you use? We are using Xen + libvmi. I have continued to read the kernel sources, and as best as I can understand it the kernel installs uprobe instrumentation if it detects a software breakpoint. Our program does not reinject the software breakpoints it services back into the guest, so I am still trying to figure out why uprobes seems to get triggered. -- Mike :wq ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Question about uprobes
I am writing some software that monitors a guest VM using virtual-machine introspection and "hijacks" system calls under certain conditions. For example, the program might inject an int3/breakpoint into the guest kernel at the entry point to sys_open. When the breakpoint is hit, the program might set the guest instruction pointer to the address to which sys_open would have itself returned and set register RAX to some desired error-code return value. The problem I am encountering is that for some reason the process is triggering a "uprobe ... failed to handle uretprobe" message from the guest kernel. I do not yet know enough about uprobes to understand what might be causing this. Is there something in procedures such as sys_open which must execute to prevent the error which causes the kernel to print this message? -- Mike :wq ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Monitoring network system calls from outside VM
I am working on a system which will monitor the system calls serviced by an operating system running inside a VM. All of the software runs outside of the VM, and I wish to avoid modifying or installing software inside of the VM. Imagine an external monitor observing PID/syscall/syscall parameters and PID/syscall return values. We have a prototype running which uses Xen introspection. One difficulty is mapping packets back to the process which generated them. After observing a series of system calls, the monitor might want to deny a process's ability to send network traffic. A problem arises because the parameters to and return values from socket() and connect() or sendto() do not reveal the ephemeral port chosen by the operating system. Thus the monitor does not know which process created which packet. I had thought about watching packets. The first one which the VM generates destined to the parameters set by connect() or sendto() would likely be from the process which called connect() or sendto(). However, I am not sure the events would always work out in the right order. I think something like this might be possible even while assuming one core: Process A connect(1.1.1.1:80) Process B connect(1.1.1.1:80) Kernel sends B's three-way handshake Kernel sends A's three-way handshake Process B connect returns Process A connect returns If this happened, then the monitor would incorrectly associate B's source port with A and vice versa (because the connects and handshakes are out of order). Could the events work their way through the kernel in the way described above, assuming the OS is running on a single core? Or is the kernel written in such a way that it would preserve the expected ordering? With interrupts and scheduling points, I fear it is the former. Does anyone have an idea of how I could in the monitor associate source ports/packets with processes? The monitor can easily use VM introspection to do things like map PIDs to process names, but walking the kernel data structures to solve our packet problem using introspection is much harder. More importantly, such introspection is also fragile as data structures change across versions of Linux. Thank you, -- Mike :wq ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Identify tasks which mmap'ed file
Within the kernel and given a struct file *, is it possible to enumerate the tasks which have mmap/MAP_SHARED'ed the file? I have tried to use find_get_pages/rmap_walk on the file's f_mapping field, but this does not seem to work. I find the mapping's first page with find_get_pages, but rmap_walk does not seem to find any vma's as rmap_walk never calls the callback function I pass in. Thank you, -- Mike :wq ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
SimpleFlow: simple information-flow-based security module for Linux
Some colleagues and I have been working on SimpleFlow, a simple information-flow-based security module for Linux. Our goal is to investigate the feasibility of implementing such a security model on top of LSM and to produce a prototype which is useful for education and certain computer-security competitions. We have adopted a very simple view of information flow (we do not claim to approach HiStar, etc.). The system administrator designates some filesystem objects as "confidential" and some programs as "trusted" (both stored using extended attributes). Any process not loaded from a trusted program will become "tainted" upon reading a confidential object. The kernel transfers this taint status from process to process as a result of inter-process communication (i.e., an untainted process reads from a tainted process over an IPC channel). If a tainted process writes to the network, the packet gets its RFC 3514 evil bit set. All of this seems to sort of work. We do our best to handle the forms of IPC including shared memory. The grand multi-source transformer X11 poses a problem; we presently set X11 as trusted, but we have plans to deal with X11 in X11 as SELinux has attempted. We tried to avoid making changes to the core kernel. One such change is an additional LSM call in fs/pipe.c. The other is a #define for the RFC 3514 evil bit. For practical reasons, we have so far targeted 3.10.0. We intend to eventually port to a kernel that supports LSM stacking. We are presently preparing a paper that describes some of the things we have done with SimpleFlow, and we are interested in hearing any feedback on our approach or code. We attached a patch which represents our work so far. We realize this is niche work, and perhaps SimpleFlow itself does not belong in the mainline kernel. However, we would be keen to discuss the concept even with people who are mildly interested. Thank you, -- Mike :wq linux-3.10.0-327.el7-simple-flow.patch.gz Description: application/gzip ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Walk list of processes attached to a shared page
Is it possible to walk the processes already attached to a shared page in an implementation of security_shm_shmat()? I have a function: static int my_shm_shmat(struct shmid_kernel *shp, char __user *shmaddr, int shmflag) and I would like to find the processes already attached. It seems like rmap_walk() would help, but I cannot figure out how to get an appropriate struct page out of a struct shmid_kernel or unmapped address (i.e., shmaddr above). -- Mike :wq ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
