I want to protect other folder on the server from the system call in the program.How can it be done?
I have tried chroot but i am having problem implementing it.
Try EasySandbox.
It uses seccomp (a sandboxing mechanism in Linux kernel) for sandboxing C/C++ codes.
Related
I'd like to intercept stat calls on a specific file and quickly perform an action ASAP once detected.
In the past I've used the INotify library but thats only worked for me when opening/writing/closing files etc. If I remember correctly, stat just reads the contents of the i-node on the file system so what would be the best way of intercepting the calls with a binary running in user space?
I guess this could also be generalized to intercepting system calls from userspace?
Also want to note that I do know the process I'm targeting but don't have any control over when it runs etc.
Thanks!
It is possible with the technique is known as function interposition.
It works for applications that you start or control the start-up environment to be able to set LD_PRELOAD environment variable.
You could use function hijacking at the library level with LD_PRELOAD, but this only works for dynamically linked binaries that are not setuid/setgid. For static or setuid/setgid binaries you have to implement a kernel module to hijack the function at the kernel level.
I am interested in writing my own tool in bash to act in place of my current network controller (wpa_supplicant) if possible. For example if I want to issue commands in order to begin a wps authentication session with a router's external registrar, is it possible, without using any pre-built tools, to communicate with the kernel to directly access the hardware? I have been told that I can achieve what I desire with a bash plugin called ctypes.sh but I am not too certain.
Generally speaking, the Linux kernel can interact with user-space through the following mechanisms:
Syscalls
Devices in /dev
Entries in /sys
Entries in /proc
Syscalls cannot be directly used from Bash but you need at least a binding through a C program.
You can create a Linux kernel driver or module which reads/writes data in an entry under /proc or /sys and then use a bash program to interact with it. Even if technically feasible, my personal opinion is that it is an overkill, and the usual C/C++ user-level programming with proper entries in /dev is much better.
No, this is generally not possible. Shell scripts can mess around in /proc, but they don't have the ability to perform arbitrary IOCTLs or even multi-step interactive IO. It's the wrong tool for the job.
I am curious about mechanism of Linux compatibility layer of FreeBSD and got some info below.
https://en.wikipedia.org/wiki/FreeBSD#Compatibility_layers_with_other_operating_systems
https://unix.stackexchange.com/questions/172038/what-allows-bsd-to-run-linux-binaries-but-not-vice-versa
The key difference between two OSes is difference of system calls.
And, I know Linux app and BSD app depend on different standard dynamic libraries (linux-gate.so.1 for example).
Is there anything else in the implementation?
The approach to being able to run Linux apps in FreeBSD is multi-faceted.
The parts of the strategy, as I understand it, are as follows:
Provide a system call layer that mimics as close as it can the Linux system call structure and semantics. In FreeBSD, this layer is called 'the linuxolator'
Install a set of vanilla pre-compiled Linux userland libraries. These libraries work because the linuxolator provides the right system calls that they depend on.
Install/provide/mount platform services that Linux userland libraries and apps expect. For example:
Mount a Linux-compatible procfs - linprocfs.
Install pre-compiled Linux apps and have them depend on these Linux userland libraries.
The Linux Apps call the Linux libraries which call the Linuxolator's Linux system calls which call the FreeBSD system calls.
Some functionality is available on Linux (udev, systemd, inotify(7), ...) but not on FreeBSD (and probably vice versa).
Some system calls have different flags. FreeBSD mmap(2) is not exactly the same as Linux mmap(2), etc...
Both are Unix systems, but the devil is in the details.
If you want to code in C an application for both OSes, try hard to follow POSIX.
I am looking at some code that uses a function detour package called DetourXS. My application is targeted for Microsoft Server operating systems. Microsoft Research also has a Detours package and they have an article on how it works. They patch the machine code that is loaded in memory and insert code that makes an unconditional jump into the newly injected code.
If this code works by modifying the machine code at run time, they should be facing security restrictions by the Operating System. This would be a serious security lapse on the OS as I can modify any critical DLL like kernel32 to do anything I want. My understanding is that if a user process attempts to modify the code of a dll already loaded into memory, it should be stopped by the OS. Is there a setting in Widows Server OS to enable/disable this check?
How do they overcome this?
Does anybody have experience on using this kind of detour packages in any application in enterprise production environment?
First important thing is that with detours you modify the instructions of your own process. In your process - you can do whatever you want anyways and you don't even have to detour anything, from OS point of view userspace code (e.g. code in your DLL and code in system's kernel32.dll loaded into your process) is exactly the same from security point of view. The reason is simple - hacking security of OS is not the same as changing some code of your process in userspace. OS secures itself by not giving your process too much power (unless you're running as an administrator). For security purposes it is more interesting how to modify code of another process (to achieve its privileges or interesting data, like passwords), but it is a subject for a different discussion.
Secondly, detouring had been considered as a way to implement hot-patching, i.e. patching critical system services on the fly, without reboot. I don't know whether it is currently used/supported by Microsoft (according to google it is), but it is not by chance that standard prolog has length of 5 bytes (yes, it is ideal for putting your jmp instruction).
Despite its name, kernel32.dll is not actually the kernel; it contains the entry points to Win32 API functions that implement Win32's interface to NT system calls.
Furthermore, Windows (like any modern OS) supports copy-on-write, so if you use detours to patch a shared DLL like kernel32.dll, the OS will first make a private copy for your process and patch that. The NT kernel itself is perfectly safe.
Can I run some some custom code at the time when GRUB loads up? In other words does GRUB provide a facility to run some custom code before loading any operating system?
Since GRUB support the Multiboot specification, yes you can. You would get your code loaded by GRUB, then you'll have to load the operating system yourself (which you could do by supporting the Multiboot specification yourself...). Depending on what you want to do, that may not be the easiest way to do it.
If you want to run some custom code before loading a linux-based operation system, creating a custom initramfs would be a lot easier.