oss-sec mailing list archives
Re: Re: CVE-2023-2002: Linux Bluetooth: Unauthorized management command execution
From: Steffen Nurpmeso <steffen () sdaoden eu>
Date: Thu, 20 Apr 2023 00:11:44 +0200
nightmare.yeah27 () aceecat org wrote in <20230419055256.zhwa4okfxdbsc72z@beesty>: |On Tue, Apr 18, 2023 at 02:57:41AM +0200, Solar Designer wrote: |> On Sun, Apr 16, 2023 at 10:57:27PM +0200, Steffen Nurpmeso wrote: | |>> You have to do some things, and if you give up privileges |>> thereafter, extended capabilities are gone. | |> POSIX saved IDs should help retain/regain the capabilities. | |Another (simpler?) way is to fork before giving up privilege. So it ends up, logically torn into individual pieces, each of which with diverted privileges, that all communicate via CMSG or shared memory (file maps). OpenBSD at least provided a nice syslog syscall, for FreeBSD and Linux i even had to split out logging via syslog(3) to a dedicated logger process, since who knows what the C libraries do to get that done, and that is only today -- who knows what they do tomorrow. So many context switches, so many detours for each and every thing. Having said that, audio goes these long roads for most of you (i'd say), so a litte log message is not a thing. But, you know, if you have some work to do that involves network traffic, including DNS resolving, and TLS, then this process (a thread cannot be it .. except maybe on Linux when you unroll it through adapted clone(2)) should still be constrained via pledge/unveil / capsicum / seccomp, no? And this seems to be a very complicated thing to do given all the libraries one has to use; isn't this a maintenance nightmare? So i was thinking; i mean the BSDs are holistical, which, if you build only upon facilities in the base system, is maybe doable. But Linux? --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt)
Current thread:
- Re: CVE-2023-2002: Linux Bluetooth: Unauthorized management command execution, (continued)
- Re: CVE-2023-2002: Linux Bluetooth: Unauthorized management command execution Steffen Nurpmeso (Apr 16)
- Re: CVE-2023-2002: Linux Bluetooth: Unauthorized management command execution Jakub Wilk (Apr 16)
- Re: CVE-2023-2002: Linux Bluetooth: Unauthorized management command execution Steffen Nurpmeso (Apr 17)
- Re: CVE-2023-2002: Linux Bluetooth: Unauthorized management command execution Solar Designer (Apr 17)
- Re: CVE-2023-2002: Linux Bluetooth: Unauthorized management command execution Ruihan Li (Apr 18)
- Re: CVE-2023-2002: Linux Bluetooth: Unauthorized management command execution Todd C. Miller (Apr 18)
- Re: CVE-2023-2002: Linux Bluetooth: Unauthorized management command execution Ruihan Li (Apr 18)
- Re: CVE-2023-2002: Linux Bluetooth: Unauthorized management command execution Todd C. Miller (Apr 18)
- Re: CVE-2023-2002: Linux Bluetooth: Unauthorized management command execution Steffen Nurpmeso (Apr 18)
- Re: CVE-2023-2002: Linux Bluetooth: Unauthorized management command execution Jakub Wilk (Apr 16)
- Re: CVE-2023-2002: Linux Bluetooth: Unauthorized management command execution Steffen Nurpmeso (Apr 16)
- Re: CVE-2023-2002: Linux Bluetooth: Unauthorized management command execution nightmare . yeah27 (Apr 19)
- Re: Re: CVE-2023-2002: Linux Bluetooth: Unauthorized management command execution Steffen Nurpmeso (Apr 20)
- Re: CVE-2023-2002: Linux Bluetooth: Unauthorized management command execution 0xef967c36 (Apr 18)
- Re: CVE-2023-2002: Linux Bluetooth: Unauthorized management command execution Ruihan Li (Apr 18)
- Re: CVE-2023-2002: Linux Bluetooth: Unauthorized management command execution 0xef967c36 (Apr 18)
- Re: CVE-2023-2002: Linux Bluetooth: Unauthorized management command execution Solar Designer (Apr 18)
- Re: CVE-2023-2002: Linux Bluetooth: Unauthorized management command execution 0xef967c36 (Apr 18)
- Re: CVE-2023-2002: Linux Bluetooth: Unauthorized management command execution Steffen Nurpmeso (Apr 18)