Yes and no. Usage of this syscall is guarded by an euid check. If the euid is 0 it can be used on any team (except B_SYSTEM_TEAM). Otherwise, the euid of both the source and target teams must match the caller’s euid. This is the same check as Haiku’s _kern_install_team_debugger syscall.
In the patch I have included a test asserting that this function should fail for a child process after dropping its root privileges.
Without this syscall we can already arbitrarily read, write, and otherwise modify the address space of any team by using debugger APIs. Having a new call that is as restrictive as _kern_install_team_debugger should not cause any security issues.
clone_area, on the other hand, seems to work on any userland area, regardless of the target area’s owner’s euid. Therefore, the B_CLONEABLE_AREA flag is needed.
Maybe, I will change it to clone_memory (and the corresponding flag, MAP_CLONE).
I am not sure that double mapper is actually useful on Haiku. It do not affect functionality, but waste resources. Security benefits are also suspicious. On 32 bit virtual address space waste may be serious problem.
And those should probably check that you are UID 0 before allowing arbitrary debugger attachments. The fact that basically everything runs as UID 0 at present makes this check moot most of the time. Nonetheless we should have it.
For now. It used to not be required at all, and you could clone anything. More restrictions should get added in the future, probably.
I think we shouldn’t have an extension mmap flag at all, and have a completely separate function be the only way to do this.
But I also agree with this. I really think we should just set WriteXorExecute=0 and quit worrying about it.
You might want to look at how ptrace and process_vm_readv checks on Linux then. Apart from the euid check, depending on the system setting, these two syscall additionally requires the caller process to be an ancestor of the target.
If you don’t like this centralized vm_remap-style API, then might it be better if I implemented process_vm_readv, FreeBSD mremap and a custom commit_memory instead?
For the debugger, applications should be able to protect themselves, for example by using disable_debugger/enable_debugger (I don’t know if that already works, but it sounds like these should protect from attaching a debugger).
So, the fact that a security problem exists with this is not a reason to open an even wider security problem.
If we both agree that it might be useful, then this patch should be eventually merged, shouldn’t it (not trying to rush the review process or anything, just trying to say that it should not be completely rejected)?
On the CoreCLR side, in the end it’s the people at dotnet who ultimately decides whether some code/an approach is acceptable or not.
public class Test : BApplication
private BWindow _window;
public Test() : base("application/x-vnd.Test")
_window = new BWindow(new BRect(100, 100, 300, 300), "Test", WindowType.B_TITLED_WINDOW, 0, 0);
public static void Main()
var application = new Test();
What do you think of this kind of programming?
This is the current state of Haiku C# API bindings, generated using CppSharp by Mono.
There are a few issues related to the native portion of the bindings (a special shared library that is created in order to keep inlined functions alive), so the thing isn’t working correctly at runtime yet.