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.
I might pick this up again one day if the HaikuPorts folks ported this thing to Haiku (compilation is trivial, but there are some tricky bugs somewhere).
There are some native components, but these can build on Haiku without any patches; the only thing needed is for someone to write up a recipe for those and all FNA games can run unmodified.
Actually there are some parts of the kernel that might benefit from this (IO routines handling userspace buffers which presently use either lock_memory or clone_area for example.)
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.
using Haiku.App;
using Haiku.Interface;
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);
_window.Show();
}
public static void Main()
{
var application = new Test();
application.Run();
}
}
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.