GDB on VSCodium

[neat furnace]

Hi, I'm trying to debug C++ using the native debugger extension on the VSCodium flatpak. I've layered gdb onto my system, and pointed the native debug config file to its executable. It launches successfully, but finds it's unable to trace the inferior process and quits.

warning: Could not trace the inferior process.
warning: ptrace: Operation not permitted```

i gave the vscodium flatpak access to development syscalls but i'm not sure that is exactly what's going wrong here

[amber tapir]

maybe it's the wider ptrace scope?

[amber tapir]

@neat furnace https://www.kernel.org/doc/html/latest/admin-guide/LSM/Yama.html
in /etc/sysctl.d/60-hardening.conf on secureblue, kernel.yama.ptrace_scope is set to 3. you'll need to set it to 0, 1 or 2

ideally 2, and then use setcap on your IDE to give CAP_SYS_PTRACE? idk how that'll work with flatpak

[neat furnace]

are debug syscalls like this dangerous to allow

[teal niche]

Flatpak will scrub off capabilities

[amber tapir]

well, ptrace allows one process to control and read the memory of another, because that's what a debugger does

by default on linux, without yama, every process can do that to every other process i think

so it's best to restrict it in some way

[neat furnace]

does this mean it isn't possible to call gdb through the vscodium flatpak?

[amber tapir]

it would be

just not with kernel.yama.ptrace_scope=2

i was suggesting setting it to 2 (better than 0 or 1) and then giving vscode the CAP_SYS_PTRACE capability

so you can avoid letting other apps use ptrace

instead, you might have to set it to 1

fwiw this isn't a secureblue limitation: other distros set the ptrace scope wayy too permissively, as it turns out

[neat furnace]

yeah

[neat furnace]

flatpak cant use setcap so yeah ahghhbevwhs

but it feels like

if every flatpak has ptrace

even if i don't give an app any particular permissions

it can monitor the memory of every other program and still overreach

[amber tapir]

that's with scope 0

[amber tapir]

scope 1 means the program can only ptrace related processes, e.g. its children

and also flatpak has a ptrace toggle, the devel one

so not every flatpak would get it iirc

[neat furnace]

sweet

so scope 1 + devel should be typical functionality for vscodium w/o breaking my security

(i actually think scope 2 + setcap would be worse since a ptrace admin can change the ptrace level to 0 and monitor any other program, so if there was some malware in an extension or something)

[amber tapir]

yeah, i think several secureblue users do that

still a degradation, but better than 0

[amber tapir]

oh wow

they should really have separated that cap

[neat furnace]

i mean in what case could a process monitoring the memory of a child process be a bad thing? they have full control over the child process anyways

[amber tapir]

ah, i just checked and it seems you can only ptrace the direct child

which would break IDEs anyway

best to use a VM then

iirc @distant lake writes C++ on a hardened system, idk how they do it

[distant lake]

A text editor and clang 🙂

I hate IDEs

For debugging yeah, a VM

[amber tapir]

c, c++ and rust culture is quite different from c#/java lol

[teal niche]

AFAIK most Rust devs use VSCode

[amber tapir]

vscode can be anywhere in-between a text editor and IDE though right?

[teal niche]

Basically

[neat furnace]

so ptrace scope 1 actually worked seemingly

kind of

Not really sure what's happening here

this is my debugger config

but like

everything i send to gdb gets scrambled?

the good news is gdb runs? 😭

oh it should be my debug program

weird

nvm it just works

sure hope ptrace scope 1 isn't insecure

[carmine vale]

You don't need to layer gdb, just use brew.

[neat furnace]

what would this change?