I need to know is it possible to intercept user executed command in loadable kernel module. I know that system calls can be intercepted such as open(). But what i need to do is intercepts user entered command/ process and add some validations. for example, if user enters cp command, before executing the command i need to perform some validations against it. If we cannot do this in LKM, what are the alternative approaches?
You need to look up how many actual system calls there are for execvp() and friends (probably 1, maybe 2 — it could be more, but probably isn't), and then intercept those system calls. You might need to worry about posix_spawn() and friends too. They're the only ways that new processes can be run. There isn't any other way to intercept them.
You could try using an LKM or a systemtap plugin(which compiles to an LKM). The kernel functions that you should hook are execve and execveat. In case you are doing this for programming fun and want to write hooking code by yourself, you might want to look at kprobes and know that you can get kernel function addresses from /proc/kallsyms.
Of course, recompiling the kernel with your own hooking code is another option if that is a possibility.
In both the cases above you probably want to intercept the execve calls made by a specific uid; if so, you should filter calls from that uid.
A userspace approach might be to try writing a seccomp filter. Here is a tutorial on how to go about writing one.
Related
I don’t mean locking the file!
What I want to achieve is that all other threads should access the file without any problem, but in some circumstances I want to fail calls which are accessing that file through fd like dup2(2), ftruncate(2), etc. One option is to make a wrapper for all such functions like dup2(2), that will first check if to allow fd or no and then call the real dup2(2). But its a long task to do it with every sys call using fd.
Maybe if there is a solution to password protect a file so that it can only be accessed when specified password is given.
My library is being injected to anonymous process so I don’t have control over the caller and I observe that anonymous process doesn’t check fd before using it. It ends up using the fd my library is using.
Kindly don’t complain about the design issues. Please just focus on problem.
It sounds like you're injecting a library into a process that has a different constrained memory model and your library is incompatible. You could try using dup2() to move your own handles to really high values and hope it works.
Through in a mutex lock and make it so that if a thread wants to access the file then it has to do so through that function?
I'm creating a simple network scanning function using nmap and C. I want to use popen() to execute nmap, but nmap takes close to 30 seconds to complete because I'm scanning a wide range of IPs.
So, is there a way to check when the command has finished executing? I don't want my C code to hang at the system call, instead I would like to just check a flag or something in a loop that will know when popen/nmap has finished so other parts of my C program don't come to an halt. Is this possible??
Thanks!
I can think of 2 direct ways to do it
You could fork() directly and then establish a way to communicate the two processes, this would be very difficult because IPC is not an easy matter.
You could create a new thread with pthread_create() and call popen() there, it would be a lot easier and you could share data between threads by using an appropriate locking mechanism to prevent race conditions.
You can either use multi processing with fork (hardmode)
Or you can use multithreading using pthread (easymode)
Either one allows you to do 2 things at once. Multiprocessing is hard because you must worry about innerproccess communications (pipes) and the 2 tasks you're trying to do can not share memory.
Multithreading is a much more easy because all you need is to include the libraries (-lpthread) and then specify what function is on the seperate thread.
I'm writing a program that spawns child processes. For security reasons, I want to limit what these processes can do. I know of security measures from outside the program such as chroot or ulimit, but I want to do something more than that. I want to limit the system calls done by the child process (for example preventing calls to open(), fork() and such things). Is there any way to do that? Optimally, the blocked system calls should return with an error but if that's not possible, then killing the process is also good.
I guess it can be done wuth ptrace() but from the man page I don't really understand how to use it for this purpose.
It sounds like SECCOMP_FILTER, added in kernel version 3.5, is what you're after. The libseccomp library provides an easy-to-use API for this functionality.
By the way, chroot() and setrlimit() are both system calls that can be called within your program - you'd probably want to use one or both of these in addition to seccomp filtering.
If you want to do it the ptrace way, you have some options (and some are really simple). First of all, I recommend you to follow the tutorial explained here. With it you can learn how to know what system calls are being called, and also the basic ptrace knowledge (don't worry, it's a very short tutorial). The options (that I know) you have are the following:
The easiest one would be to kill the child, that is this exact code here.
Secondly you could make the child fail, just by changing the registers with PTRACE_SETREGS, putting wrong values in them, and you can also change the return value of the system call if you want (again, with PTRACE_SETREGS).
Finally you could skip the system call. But for that you should know the address after the system call call, make the intruction register point there and set it (again, with PTRACE_SETREGS).
I want to call one command(user defined) from C program(Windows).
Can you tell me the function available?
system() is the simplest way to call external programs.
It's a matter of doing something like:
system ("runme.exe");
The Win32 API has a lot of process control calls as well, which give you better control and monitoring. Look for CreateProcess and its brethren.
When trying to implement an asynchronous API calls / Non-blocking calls, I know a little in a All Plain-C application I have, I read a about APM (Asynchronous Programming Model) by 'Delegates'. Basically what I want to do is call one API f1() to do a functionality(which takes long time 8-10 seconds), So I call that API f1(), forget about it, and continue doing some other work, e.g. I/O for to fetch data for next call of the f1() or some functionality not dependent on result of f1().
If any one has used that APM model of programming, I am looking at some concise explanation for implementing non-blocking calls.
Is there any other way of implementing asynchronous APIs , any other library/framework which might help in this?
You basically need to create a multi-threaded (or multi-process) application. The f1() API needs to spawn a thread (or process) to process the data in a separate execution space. When it completes, the f1() routine needs to signal the main process that the execution is done (signal(), message queues, etc).
A popular way to do asynchronous programming in a plain C programs is to use an "event loop". There are numerous libraries that you could use. I suggest to take a look at
glib.
Another alternative is to use multiple pre-emptive threads (one for each concurrent operation) and synchronize them with mutexes and condition variables. However, pre-emptive threading in plain C is something I would avoid, especially if you want to write portable programs. It's hard to know which library functions are re-entrant, signal handling in threaded programs is a hassle, and in general C libraries and system functions have been designed for single-threaded use.
If you're planning to run your application only on one platform (like Windows) and the work done with f1() is a relatively simple thing, then threading can be OK.
If the function f1() which you are referring to is not itself implemented in a asynchronous fashion, you will need to wrap it up in its own thread yourself. When doing this, you need to be careful with regards to side effects that may be caused by that particular function being called. Many libraries are not designed in a thread-safe way and multiple concurrent invocations of functions from such libraries will lead to data corruption. In such cases, you may need to wrap up the functionality in an external worker process. For heavy lifting that you mention (8-10 seconds) that overhead may be acceptable. If you will only use the external non-threadsafe functions in one thread at a time, you may be safe.
The problem with using any form of event-loop is that an external function which isn't aware of your loop will never yield control back to your loop. Thus, you will not get to do anything else.
Replace delegates with pointers to functions in C, everything else is basically same to what you have read.
Well. Basically I've seen 2 types of async API:
Interrupt. You give a call a callback which should be performed after the call. GIO (part of previously mentioned GLib) works in such a way. It is relatively easy to program with but you usually have the thread in which the callback will be run changed (except if it is integrated with the main loop as in the case of GIO).
Poll. You check if the data is available. The well-known BSD Sockets operate in such a manner. It has an advantage of not necessarily being integrated with the main loop and running callback in a specific thread.
If you program for Gnome or Gtk+-based I'd like to add that GTask seems to be a very nice (potentially nice? I haven't used it). Vala will have better support for GIO-like async calls.