microsoft / MIEngine

The Visual Studio MI Debug Engine ("MIEngine") provides an open-source Visual Studio Debugger extension that works with MI-enabled debuggers such as gdb and lldb.
MIT License
818 stars 218 forks source link

[Feature request] Way to bypass "Superuser access is required to attach to process..." dialog #1388

Open adriancostin6 opened 1 year ago

adriancostin6 commented 1 year ago

I have recently implemented a runtime fix for GDB on linux remote machines, in order for users to be able to attach to process. Basically my application calls prctl directly to enable process tracing so that users can attach to it with GDB without needing root privileges. I now wish to use VS Code to debug with GDB, but I am hit with a dialog from the MIEngine: "Superuser access is required to attach to a process. Attaching as superuser can potentially harm your computer. Do you want to continue? [y/N]", which basically blocks my use case. Is there a way to bypass this? I am up for implementing it if needed, just need some pointers.

adriancostin6 commented 1 year ago

From looking at the code so far, I have stumbled upon UnixUtilities.cs where the checks are performed in the following functions.

        internal static bool GetRequiresRootAttach(MIMode mode)
        {
            // If "ptrace_scope" is a value other than 0, only root can attach to arbitrary processes
            if (GetPtraceScope() != 0)
            {
                return true; // Attaching to any non-child process requires root
            }

            return false;
        }

        private static int GetPtraceScope()
        {
            // See: https://www.kernel.org/doc/Documentation/security/Yama.txt
            if (!File.Exists(UnixUtilities.PtraceScopePath))
            {
                // If the scope file doesn't exist, security is disabled
                return 0;
            }

            try
            {
                string scope = File.ReadAllText(UnixUtilities.PtraceScopePath);
                return Int32.Parse(scope, CultureInfo.CurrentCulture);
            }
            catch
            {
                // If we were unable to determine the current scope setting, assume we need root
                return -1;
            }
        }

From what I gather, the ptrace scope is computed and returned, based on checking the file in /proc/sys/kernel/yama/ptrace_scope, and if the return value is different than 0 you require root.

Would it be acceptable to add another case here, for people like me, that disable ptrace hardening for our specific application at runtime, so still have the ptrace_scope file present?

crhilton commented 12 months ago

We also ran into this. We've got developers that like using vscode, including for debugging, and we have a prctl call in our own code that allows gdb to attach, while keeping this security setting on for other applications. But our developers do not have super user access. So we have the choice of turning off this security feature or telling developers that they can't use vscode for debugging.

Just an option to have it try anyway in the launch configuration would be good enough, but ideally it could check if the process allows attaching.