[HN Gopher] Can we hide the orange dot without disabling SIP?
___________________________________________________________________
Can we hide the orange dot without disabling SIP?
Author : alin23
Score : 34 points
Date : 2023-03-30 18:34 UTC (4 hours ago)
(HTM) web link (notes.alinpanaitiu.com)
(TXT) w3m dump (notes.alinpanaitiu.com)
| Cockbrand wrote:
| Bartender [0] hides and rearranges icons by manipulating how the
| menu bar gets rendered. IIUC, it takes screenshots of the menu
| bar and uses them to cover certain areas of it. This might be
| another promising approach for hiding the orange dot.
|
| [0] https://www.macbartender.com/
| urbandw311er wrote:
| Kudos to the author for publishing this exploration even though
| it ultimately didn't succeed. It's still revealing and useful.
| jaggederest wrote:
| Absolutely interesting to see people using ChatGPT to wrangle
| some assembler, as well.
| stefan_ wrote:
| In good old ChatGPT fashion, it is utterly wrong, of course.
| If you are passing some unknown struct to a function, you
| should make sure you at least get the size right.
| GeoAtreides wrote:
| ChatGPT Axiom of correctness: If an answer cannot be
| googled or cannot be obtained by making trivial
| modifications to an answer found on google, most probably
| GhatGPT's answer is incorrect.
| ary wrote:
| TLDR; No, you can't (for now).
|
| This was a little bit of an uncomfortable read as I really didn't
| want to see this defeated, but I'm glad people are checking that
| it works as intended. The pessimist in me fears that when SIP
| bypasses are found this will be ready to go as part of a RAT.
| Realistically though the authors of RATs probably didn't need the
| example.
| bombcar wrote:
| Apple could just go to the expense of adding a few extra LEDs
| to the case. They already have one in Caps lock - could put one
| behind the volume button or something.
|
| Or make it only appear on the internal monitor, not mirrored or
| external devices.
| snowwrestler wrote:
| From the previous HN thread linked from this article, it seemed
| like the "officially supported" ways to avoid the orange dot for
| live performance and editing video were either a hardware capture
| device, or an app that uses an API to output raw video to a
| window/display.
|
| https://news.ycombinator.com/item?id=29627382
| exabrial wrote:
| Apple needs to allow users to defeat certain security mechanism
| without disabling SIP. The "all or nothing" approach will end up
| with a lot of people going "nothing" or leaving the platform. Not
| everyone faces the same risks.
|
| Something like (just typing this out, haven't thought it
| through): Having Apple associate your hardware with an apple id.
| Logging into apple id and registering a key. Apple signs key and
| you can install key on the specific hardware. You can then use
| said key to sign a security policy.
|
| The key can be removed by install Apple's default key by anyone,
| increasing the security level back to normal.
| rgovostes wrote:
| Apple already engineered SIP to let the user disable it with
| csrutil. It is unsupported but you can selectively disable
| parts of SIP. (You cannot Apple Pay if any flag is disabled.)
|
| https://twitter.com/theevilbit/status/1400071405207760904
| Wowfunhappy wrote:
| > Apple needs to allow users to defeat certain security
| mechanism without disabling SIP. The "all or nothing" approach
| will end up with a lot of people going "nothing"
|
| But is that _really_ so bad? For technically-inclined users, I
| 'm still largely unconvinced of the value of SIP.
|
| Either you want Apple to be in control of your computer--I
| think that's a perfectly reasonable default, if it can be
| changed--or you want to take control. If you take control, then
| by definition you must also take responsibility for delegating
| permissions to software, which you can do via the standard UNIX
| permissions model. You don't need some extra layer on top.
| threeseed wrote:
| Apple is not building laptops primarily for technical people.
|
| If you want to disable specific security mechanisms then
| disable SIP.
|
| But making that an option that developers will use to exploit
| less technical people is not good for the platform or frankly
| anyone.
| xp84 wrote:
| This is, I'm afraid, part of a vision (of which Apple is the
| preeminent sponsor but Microsoft definitely believes it too,
| they're just less aggressive) where the OS vendor is presumed to
| know best and the owner of the computer's wishes are occasionally
| considered on an "if possible" basis.
|
| Obviously they could allow whatever signatures go into SIP to be
| updated, so you could make changes and then bless your changed
| configuration, and it wouldn't really even be hard. But they
| consider most computer owners to be too stupid to be trusted with
| that kind of power. And, they do have a point, a lot of users
| would happily do any super unsafe things they're told, just in
| exchange for a promise of a free game or a cracked version of
| Photoshop or whatever.
|
| It's just sad for those of us who remember that computers used to
| really be almost infinitely customizable. If you didn't like
| something, and you cared enough, you could fix it. I assume that
| soon, SIP won't be a thing you could turn off even if you wanted,
| and while you will still be able to get a root shell on a Mac
| it'll eventually be on some virtualized entity whose permissions
| are curtailed to only a sandboxed environment.
| JumpCrisscross wrote:
| > _they could allow whatever signatures go into SIP to be
| updated, so you could make changes and then bless your changed
| configuration_
|
| What's wrong with SIP being on or off?
| koito17 wrote:
| Off the top of my head, dtrace and dyld are gimped with SIP
| enabled, and you cannot modify your system volume for
| whatever reason (yes, that means "sudo mount -uw /" fails).
| You cannot use LD_PRELOAD if SIP is enabled, even on your own
| apps. Kernel extensions also need you to disable SIP, which
| is annoying if you want to work on a kext or even install
| one.
|
| For a non-technical problem: if you want to be able to share
| your screen on apps like Discord and forward audio output,
| you have to install a kext (oops, can't do that anymore with
| SIP enabled!), or you use "system extensions" which run in
| user space and expose less APIs (oops, on Apple Silicon macs
| the user has to boot into recovery mode to temporarily
| disable some security option before system extensions can be
| loaded!)
|
| The result? A lot of Mac users are simply too wary set up
| audio output for Discord's screen sharing because it means
| having to boot into recovery mode and do a bunch of stuff
| that will scare the hell out of any non-technical user.
|
| So it's not just power users that are affected by silly Apple
| policies. Everyday users, too.
| zamnos wrote:
| I think that's magnifird by the software you use, in this
| case, Discord. I've got SIP enabled and didn't need to
| disable it for Zoom or Google Meet to do screen sharing.
| There was one permissions dialog I had to go through in
| accessibility for screen sharing to work for them, and it's
| a tiny bit scary, but that's not SIP-disable level, reboot
| into recovery mode and run _crsutil disable_ level scary.
| 0x0 wrote:
| macos 13.3 introduced another dot, a blue dot for location
| services. Unfortunately it seems to severely interfere with
| games. For example, playing Asphalt9 from the mac app store, on
| macOS 13.3, whenever the blue dot appears, which seems to happen
| almost every minute, the game's audio stops, any attached game
| controller becomes unresponsive, and if you were actively playing
| a single player race, the game pauses and shows the pause menu,
| as if you had changed focus to a different application. After
| about 10 seconds, the blue dot disappear and the game controller
| becomes responsive again, allowing you to unpause the game. This
| makes any attempt at actually playing the game an exercise in
| anger management.
| madeofpalk wrote:
| Is that a problem with _the dot_ , or a problem with the game?
___________________________________________________________________
(page generated 2023-03-30 23:01 UTC)