Hello, when I read posts like @Dan's, I say to myself: Don't feed the troll. Pointless.
Wish you all a nice weekend, Heinz Gesendet: Donnerstag, 28. März 2024 um 23:02 Uhr Von: "Jan Stary" <h...@stare.cz> An: misc@openbsd.org Betreff: Re: Security questions: Login spoofing, X11 keylogging, and sandboxed apps go away On Mar 28 21:16:45, dan.peretz...@gmail.com wrote: > You didn't "Reply All", so I didn't get your reply in my inbox. (The person > you're replying to should be in the To field, and the mailing list in the > Cc field.) > > >Even on windows; this has nothing to do with intercepting ctrl-alt-del. > False. Ctrl-Alt-Delete cannot be intercepted on Windows without first > compromising the integrity of the operating system. The Windows kernel is > hardcoded to forward Ctrl-Alt-Delete to Winlogon, and Winlogon runs in a > separate Secure Desktop mode that takes over the entire screen and no other > programs can intercept keystrokes from or send keystrokes to. > https://security.stackexchange.com/a/34975 > https://learn.microsoft.com/windows/win32/winstation/desktops[https://learn.microsoft.com/windows/win32/winstation/desktops] > > >I don't believe that's true. > >"Dear X11, what is $user typing into his firefox textarea"? > I'm not an X11 expert, and I'm not sure if the example provided in the > following link is because the program and the desktop it's running under > have different UIDs (rather than locking the desktop, logging into a > different user with a new desktop session using a SAK like Ctrl-Alt-Delete, > and running it there), but I found this old blog post, by whom I believe is > the founder of Qubes OS, being cited somewhere: > https://theinvisiblethings.blogspot.com/2011/04/linux-security-circus-on-gui-isolation.html[https://theinvisiblethings.blogspot.com/2011/04/linux-security-circus-on-gui-isolation.html] > It is common knowledge that X11 is insecure by design, not (only) by the > ancient code, so even if the blog post isn't relevant anymore, it wouldn't > surprise me if such attacks could still be done. > > >>I saw that Chromium, Firefox, and Tor Browser on OpenBSD (at least when > installed from the OpenBSD package manager/ports) are sandboxed with > pledge(2) and unveil(2). > >find /usr/ports/ -name pledge\* > Already done: > https://openports.pl/search?file=unveil[https://openports.pl/search?file=unveil] > This only lists third-party packages that have an OpenBSD ports-originated > addition of pledge/unveil configuration files; packages that use > pledge/unveil without configuration files, or whose pledge/unveil > configuration files originate from the upstream distribution, are not > listed. Chromium, Ungoogled Chromium, Firefox, Firefox ESR, and Tor Browser > are sandboxed, which is excellent because Web browsing is one of the most > popular desktop activity and browsers are meant to use networking and > execute untrusted JavaScript/WebAssembly code, and parse untrusted data > like media, CSS, etc. Contrary to servers, that if they're hacked then some > business might be ruined, personal computers are used to do banking and > shopping online, chat with distant friends/family > members/doctors/lawyers/coworkers/etc., and hold our personal thoughts and > memories, so I believe that they shouldn't get compromised just because the > user entered the wrong website on a bad day, or opened the wrong video, or > the wrong file, etc. OpenBSD already has the excellent system calls > pledge(2) and unveil(2), and already uses them extensively in the base > system and for the aforementioned browsers, but what about other programs?
