WEBVTT 1 00:00:00.080 --> 00:00:02.279 Welcome to our deep dive. Today. We're going to be 2 00:00:02.279 --> 00:00:05.400 looking at something that's both fascinating and a little bit unnerving, 3 00:00:05.719 --> 00:00:08.080 the security of Apple's operating systems. 4 00:00:08.359 --> 00:00:11.119 And to guide us through this intricate landscape, we've got 5 00:00:11.199 --> 00:00:16.000 Jonathan Levin's book OS Internal's Volume three, Security and Insecurity. 6 00:00:16.519 --> 00:00:19.960 This book is like a masterclass in how Apple builds 7 00:00:20.000 --> 00:00:25.960 those defenses, and equally important, how those defenses have been tested, challenged, 8 00:00:26.120 --> 00:00:27.320 and sometimes even broken. 9 00:00:27.600 --> 00:00:29.960 It's like getting a backstage pass to the world of 10 00:00:30.000 --> 00:00:33.000 digital security, a peak behind the curtain to see how 11 00:00:33.000 --> 00:00:35.159 the wizards at Apple try to keep our Max and 12 00:00:35.200 --> 00:00:36.880 iPhones safe exactly. 13 00:00:37.200 --> 00:00:39.359 And what Levin does so brilliantly is he takes us 14 00:00:39.399 --> 00:00:42.520 through both sides of the story, the security and the insecurity. 15 00:00:42.560 --> 00:00:44.520 It's not just about how things are supposed to work, 16 00:00:44.759 --> 00:00:46.799 it's about how they can be made to work differently, 17 00:00:47.079 --> 00:00:49.520 sometimes with unintended consequences. 18 00:00:49.600 --> 00:00:51.759 Okay, so let's start unpacking all of this. Where do 19 00:00:51.799 --> 00:00:54.000 you think we should begin. What's the foundation of all 20 00:00:54.039 --> 00:00:55.159 of the security stuff. 21 00:00:55.600 --> 00:00:58.200 Well, like any good fortress, it all starts with authentication. 22 00:00:58.719 --> 00:01:01.719 How your device knows it's really you trying to get. 23 00:01:01.520 --> 00:01:05.640 In right, So beyond the usual username and password. What's 24 00:01:05.680 --> 00:01:06.799 going on behind the scenes. 25 00:01:07.359 --> 00:01:10.480 You'd think it's just a simple check but Apple actually 26 00:01:10.599 --> 00:01:14.959 uses a multi layered approach that goes beyond those traditional methods. 27 00:01:15.040 --> 00:01:17.480 Think of it like a series of checkpoints, each with 28 00:01:17.560 --> 00:01:19.480 its own set of guards and protocols. 29 00:01:19.879 --> 00:01:22.599 Okay, I'm intrigued. Walk me through these checkpoints. 30 00:01:22.840 --> 00:01:26.439 So you have the familiar login screen, But behind that, 31 00:01:26.680 --> 00:01:30.079 there's a process called open direct read, which uses a 32 00:01:30.120 --> 00:01:33.680 Skellite database to manage user configurations. 33 00:01:32.920 --> 00:01:36.400 And data hold on scale. That's a pretty standard database format, 34 00:01:36.439 --> 00:01:38.439 isn't it the kind that anyone with a little know 35 00:01:38.480 --> 00:01:39.400 how can access. 36 00:01:39.640 --> 00:01:42.920 That's the interesting part. This database isn't locked away in 37 00:01:42.959 --> 00:01:46.599 some impenetrable vault. With the right tools and knowledge, you 38 00:01:46.640 --> 00:01:48.959 can actually pick inside and see what's going on. You 39 00:01:48.959 --> 00:01:51.000 can even manipulate certain user properties. 40 00:01:51.040 --> 00:01:53.840 Wait, are you saying that just by accessing this database, 41 00:01:53.879 --> 00:01:56.159 someone could potentially tinker with user accounts. 42 00:01:56.400 --> 00:01:59.799 Potentially. Yes, It's important to note that there are likely 43 00:02:00.040 --> 00:02:04.519 other security measures in place to prevent unauthorized modifications, but 44 00:02:04.640 --> 00:02:08.560 the fact that this database is relatively accessible highlights a 45 00:02:08.639 --> 00:02:11.840 key concept in security. It's all about layers. 46 00:02:12.080 --> 00:02:14.120 Like an Onion feel back one layer and there's another 47 00:02:14.120 --> 00:02:15.400 one underneath exactly. 48 00:02:15.919 --> 00:02:19.080 No single mechanism is fool proof. Security relies on a 49 00:02:19.120 --> 00:02:23.280 combination of interlocking defenses, each providing a different level of protection. 50 00:02:23.800 --> 00:02:27.240 Okay, so we've got this squarelight database managing user info. 51 00:02:27.560 --> 00:02:31.120 What else is involved in this multi layered authentication system. 52 00:02:31.240 --> 00:02:34.800 Well, in addition to those traditional mechanisms, Apple also introduce 53 00:02:34.840 --> 00:02:37.280 something called the Local Authentication Framework. 54 00:02:37.479 --> 00:02:39.439 What's the purpose of that? Is it like a more 55 00:02:39.479 --> 00:02:41.039 advanced form of authentication. 56 00:02:41.560 --> 00:02:44.280 You could say that it's designed to provide a standardized 57 00:02:44.280 --> 00:02:47.719 and secure way for developers to build authentication features into 58 00:02:47.759 --> 00:02:50.800 their apps. I think touch, id, face, ID, those kinds 59 00:02:50.800 --> 00:02:51.039 of things. 60 00:02:51.159 --> 00:02:54.960 Ah, So it's about streamlining the process for both developers 61 00:02:55.000 --> 00:02:57.560 and users while also making it more secure. 62 00:02:57.800 --> 00:03:00.800 Right, and it aims to create a more concert experience 63 00:03:00.800 --> 00:03:04.439 across all Apple devices. So whether you're using your iPhone, 64 00:03:04.479 --> 00:03:08.639 your iPad, or your Mac, the authentication process feels familiar 65 00:03:08.639 --> 00:03:09.319 and reliable. 66 00:03:09.520 --> 00:03:12.319 That makes sense. So we've got this multi layered system 67 00:03:12.360 --> 00:03:15.680 in place to verify our identity. What happens once we're 68 00:03:15.680 --> 00:03:18.240 in How does the system keep track of what we're doing, 69 00:03:18.319 --> 00:03:20.000 especially from a security standpoint? 70 00:03:20.120 --> 00:03:22.759 That's where auditing comes in. Think of it as a 71 00:03:22.800 --> 00:03:25.879 digital trail of breadcrumbs that records security related events on 72 00:03:25.919 --> 00:03:26.319 your Mac. 73 00:03:26.439 --> 00:03:29.919 So every time something important happens, like accessing a protected 74 00:03:29.960 --> 00:03:32.719 file or changing a system setting, it gets logged. 75 00:03:32.800 --> 00:03:35.479 Exactly. It's like having a security camera that's always watching, 76 00:03:36.280 --> 00:03:38.560 but instead of video footage, it records a log of 77 00:03:38.599 --> 00:03:42.599 actions and events. This information can be invaluable for forensic 78 00:03:42.639 --> 00:03:44.879 analysis if there's ever a security breach. 79 00:03:45.080 --> 00:03:47.759 That makes sense, like being able to retrace your steps 80 00:03:47.840 --> 00:03:50.360 if something goes wrong. But how does the system decide 81 00:03:50.360 --> 00:03:52.840 what to audit in the first place. It can't possibly 82 00:03:52.840 --> 00:03:54.120 log everything we do, right. 83 00:03:54.360 --> 00:03:58.000 That's where another key player enters the scene. KATHUUF, Apple's 84 00:03:58.080 --> 00:04:00.680 kernel level authorization system KAUF. 85 00:04:01.319 --> 00:04:03.479 Never heard of it. What's its role in all of this? 86 00:04:04.120 --> 00:04:07.280 KUF is one of those behind the scenes mechanisms that 87 00:04:07.400 --> 00:04:11.360 most users never interact with directly, but it plays a 88 00:04:11.360 --> 00:04:13.719 crucial role in deciding which actions are allowed and which 89 00:04:13.719 --> 00:04:17.040 ones aren't. Think of it like a security checkpoint within 90 00:04:17.079 --> 00:04:18.399 the core of the operating system. 91 00:04:18.439 --> 00:04:20.600 So it's like a bouncer at a club deciding who 92 00:04:20.600 --> 00:04:21.800 gets in and who stays out. 93 00:04:21.839 --> 00:04:24.959 That's a good analogy. But instead of looking at IDs, 94 00:04:25.199 --> 00:04:28.639 CAUTH uses something called scopes to define areas of interest 95 00:04:28.680 --> 00:04:30.160 for authorization scopes. 96 00:04:30.199 --> 00:04:32.759 Okay, now you're losing me. What exactly is a scope 97 00:04:32.920 --> 00:04:33.879 in this context? 98 00:04:34.120 --> 00:04:37.319 Imagine you have different security zones within a building. Some 99 00:04:37.519 --> 00:04:40.720 areas are open to everyone, while others require special clearance 100 00:04:40.720 --> 00:04:43.759 to enter. Scopes in CAUTH work in a similar way. 101 00:04:44.279 --> 00:04:48.160 They define different categories of actions or resources that require authorization. 102 00:04:48.439 --> 00:04:51.279 So different scopes for different levels of sensitivity. Can you 103 00:04:51.279 --> 00:04:52.439 give me a concrete example? 104 00:04:52.600 --> 00:04:55.879 Absolutely? One example is the coth scope of generic scope, 105 00:04:56.199 --> 00:04:58.600 which covers a wide range of actions. Then you have 106 00:04:58.639 --> 00:05:02.720 more specific scopes like cost co process, which focuses specifically 107 00:05:02.720 --> 00:05:06.360 on actions related to processes like launching a new app 108 00:05:06.600 --> 00:05:08.160 or terminating an existing one. 109 00:05:08.360 --> 00:05:12.319 Interesting. So each scope is like a specific security domain 110 00:05:12.720 --> 00:05:15.079 with its own set of rules and permissions. 111 00:05:15.199 --> 00:05:18.120 Precisely, and here's where it gets really clever. Whenever an 112 00:05:18.120 --> 00:05:22.240 action falls under a particular scope, coth triggers a corresponding 113 00:05:22.240 --> 00:05:23.040 callback function. 114 00:05:23.439 --> 00:05:24.800 A callback function, what does that do? 115 00:05:25.279 --> 00:05:27.000 Think of it like an alarm that goes off when 116 00:05:27.040 --> 00:05:30.199 something specific happens. In this case, the alarm triggers a 117 00:05:30.199 --> 00:05:33.120 piece of code that checks whether the action is allowed 118 00:05:33.720 --> 00:05:35.720 based on predefined rules and policies. 119 00:05:35.800 --> 00:05:38.240 So it's like having a security guard stationed at each 120 00:05:38.319 --> 00:05:41.000 checkpoint who checks your credentials before letting. 121 00:05:40.800 --> 00:05:43.560 You through, exactly, And it's all happening at the kernel level, 122 00:05:43.879 --> 00:05:46.560 which is the heart of the operating system. This means 123 00:05:46.560 --> 00:05:49.360 that COTH has a very low level and fundamental role 124 00:05:49.439 --> 00:05:50.600 in enforcing security. 125 00:05:50.839 --> 00:05:54.439 So code is like the gatekeeper, checking credentials and making decisions. 126 00:05:55.160 --> 00:05:57.600 But where do those credentials come from in the first place? 127 00:05:57.680 --> 00:05:59.879 Are we still talking about user names and passwords? 128 00:06:00.439 --> 00:06:04.079 Actually, this is where things get even more interesting. COTH 129 00:06:04.560 --> 00:06:08.240 uses its own system of credentials that are distinct from 130 00:06:08.279 --> 00:06:12.839 traditional POSXX credentials, which are the ones associated with usernames 131 00:06:12.839 --> 00:06:13.480 and passwords. 132 00:06:13.839 --> 00:06:16.279 Wait, different credentials. Why would they do that? Isn't that 133 00:06:16.319 --> 00:06:18.279 making things unnecessarily complicated? 134 00:06:18.759 --> 00:06:21.399 It might seem that way at first, but there's a 135 00:06:21.439 --> 00:06:25.120 good reason for this separation. It ties into Apple's Mandatory 136 00:06:25.160 --> 00:06:30.120 Access Control MAAC framework, which is another crucial layer of 137 00:06:30.120 --> 00:06:31.800 security that will dive into in a moment. 138 00:06:31.879 --> 00:06:33.759 Okay, I'm starting to see how all of these pieces 139 00:06:33.759 --> 00:06:37.600 are connected. It's like a chain reaction. One security mechanism leading. 140 00:06:37.319 --> 00:06:40.680 To the next exactly, and MAAC relies on these KUTH 141 00:06:40.759 --> 00:06:45.000 credentials to enforce its security policies. So understanding how cualth 142 00:06:45.120 --> 00:06:48.680 works is essential for grapping the bigger picture of how 143 00:06:48.720 --> 00:06:50.600 Apple secures its operating systems. 144 00:06:50.839 --> 00:06:53.120 All right, you've peaked my curiosity. Let's talk about this 145 00:06:53.240 --> 00:06:55.519 MAAC framework. What is it and how does it fit 146 00:06:55.560 --> 00:06:57.079 into this whole security puzzle. 147 00:06:57.360 --> 00:06:59.600 Think of MSS as the judge and jury in the 148 00:06:59.639 --> 00:07:04.199 court of your operating system. It's responsible for evaluating whether 149 00:07:04.240 --> 00:07:07.199 an action should be permitted based on a system of 150 00:07:07.279 --> 00:07:11.040 labels and policies, and it's deeply integrated with the kernel, 151 00:07:12.079 --> 00:07:15.000 which means it's very difficult to bypass or tamper. 152 00:07:14.759 --> 00:07:18.000 With labels and policies. This sounds very official. Can you 153 00:07:18.000 --> 00:07:18.759 break it down for me? 154 00:07:18.879 --> 00:07:23.279 Sure, every object in the system, whether it's a file, 155 00:07:23.439 --> 00:07:26.879 a process, or even a network socket, can be tagged 156 00:07:26.920 --> 00:07:29.279 with an a mass label. Think of it like a security 157 00:07:29.279 --> 00:07:30.959 clearance level for digital objects. 158 00:07:31.079 --> 00:07:33.759 So some files might be marked as top secret while 159 00:07:33.759 --> 00:07:35.439 others are public exactly. 160 00:07:35.519 --> 00:07:38.480 And then you have policies, which are essentially rules that 161 00:07:38.519 --> 00:07:41.160 determine how objects with different labels can interact. 162 00:07:41.240 --> 00:07:43.920 So a top secret file can't be accessed by someone 163 00:07:43.959 --> 00:07:45.399 with a public clearance level. 164 00:07:45.480 --> 00:07:48.519 You got it. It's all about controlling access based on 165 00:07:48.560 --> 00:07:52.480 these labels and policies, ensuring that sensitive information and resources 166 00:07:52.639 --> 00:07:54.600 are protected from unauthorized access. 167 00:07:54.720 --> 00:07:57.639 This is fascinating. It's like a whole security ecosystem operating 168 00:07:57.680 --> 00:08:00.240 beneath the surface of our max. Now, the book also 169 00:08:00.279 --> 00:08:03.040 mentioned something called texts in relation to M SICK. What 170 00:08:03.079 --> 00:08:03.439 are those? 171 00:08:03.639 --> 00:08:07.160 Texts? Are kernel extensions. They're basically little pieces of code 172 00:08:07.199 --> 00:08:10.920 that extend the kernel's functionality, and some texts are dependent 173 00:08:10.959 --> 00:08:13.279 on MAC for their operation. 174 00:08:13.279 --> 00:08:16.480 Meaning they rely on MAS for security checks and enforcement. 175 00:08:17.120 --> 00:08:19.639 That's right. The book even shows you how to use 176 00:08:19.639 --> 00:08:23.600 a simple command line tool to identify these MAC dependent texts. 177 00:08:24.079 --> 00:08:26.399 It's a good example of how Levin provides not just 178 00:08:26.480 --> 00:08:31.279 theoretical knowledge, but also practical insights into how these mechanisms work. 179 00:08:31.360 --> 00:08:35.360 That's really cool. So we've covered authentication, auditing, COTH, and MA. 180 00:08:35.879 --> 00:08:38.200 It seems like we're building up a pretty solid understanding 181 00:08:38.240 --> 00:08:41.720 of Apple's security layers. What's next on our journey. 182 00:08:42.120 --> 00:08:44.879 Let's talk about code signing, Apple's way of guaranteeing the 183 00:08:44.879 --> 00:08:48.240 integrity and origin of executable code. Think of it like 184 00:08:48.279 --> 00:08:51.600 a digital signature that verifies the authenticity of an app 185 00:08:51.679 --> 00:08:52.360 or software. 186 00:08:52.480 --> 00:08:54.879 So it's how Apple ensures the apps were downloading and 187 00:08:54.919 --> 00:08:57.799 running are legitimate and haven't been tampered with, like a 188 00:08:57.799 --> 00:08:58.679 seal of approval. 189 00:08:58.759 --> 00:09:01.600 Exactly, every piece of software that runs on mac os 190 00:09:01.600 --> 00:09:05.080 and iOS has a code signature attached to it. This 191 00:09:05.159 --> 00:09:09.360 signature is cryptographically generated, which means it's very difficult to forge. 192 00:09:09.559 --> 00:09:12.559 Okay, but what does this signature actually look like? How 193 00:09:12.559 --> 00:09:14.200 does it work on a technical level? 194 00:09:14.360 --> 00:09:17.480 Well, get ready to dive a bit deeper, because it 195 00:09:17.519 --> 00:09:19.159 involves something called the superblob. 196 00:09:19.600 --> 00:09:22.600 Superblob sounds a bit intimidating. 197 00:09:22.159 --> 00:09:24.600 Don't worry, it's not as scary as it sounds. It's 198 00:09:24.639 --> 00:09:29.360 basically a container that holds various pieces of information, including 199 00:09:29.399 --> 00:09:32.759 the actual signature itself, which is based on something called 200 00:09:32.840 --> 00:09:37.960 CMS Cryptographic Message syntax. And then there are these special 201 00:09:38.000 --> 00:09:42.240 slots within the superblob for storing additional metadata metadata. 202 00:09:42.279 --> 00:09:43.960 What kind of information are we talking about here? 203 00:09:44.000 --> 00:09:47.000 This is where things get really interesting. These special slots 204 00:09:47.000 --> 00:09:50.320 can contain things like entitlements, which we'll discuss later, but 205 00:09:50.360 --> 00:09:52.120 for now, just know that they add an extra layer 206 00:09:52.120 --> 00:09:54.120 of control over what an app can do. 207 00:09:54.639 --> 00:09:58.080 Okay, entitlements sound intreating, But first, tell me more about 208 00:09:58.120 --> 00:10:01.120 this superblob. Can we actually see it? Can we examine 209 00:10:01.120 --> 00:10:01.799 its contents? 210 00:10:02.039 --> 00:10:05.320 Absolutely? The book walks you through how to extract and 211 00:10:05.360 --> 00:10:08.679 inspect code signatures using the command line tools. You can 212 00:10:08.679 --> 00:10:11.759 actually see the structure of the superblob in its different components. 213 00:10:11.919 --> 00:10:14.879 So we can peek under the hood and see how 214 00:10:14.879 --> 00:10:19.639 this digital signature is constructed. Very cool. What else is 215 00:10:19.639 --> 00:10:21.440 important about these code signatures? 216 00:10:21.759 --> 00:10:24.639 They also include flags that influence how the code can 217 00:10:24.679 --> 00:10:27.879 be executed. These flags control things like whether the code 218 00:10:27.919 --> 00:10:31.919 can be debugged or injected into other processes, So another 219 00:10:31.919 --> 00:10:34.279 way Apple tries to limit what malicious actors can do. 220 00:10:34.440 --> 00:10:37.120 So it's not just about verifying the integrity of the 221 00:10:37.159 --> 00:10:40.960 code itself, it's also about controlling how that code behaves 222 00:10:41.279 --> 00:10:43.799 once it's running on the system. Another layer of security. 223 00:10:44.000 --> 00:10:46.600 You've got it. It's all about making it as difficult 224 00:10:46.639 --> 00:10:51.679 as possible for attackers to exploit vulnerabilities and compromise the system. 225 00:10:51.720 --> 00:10:53.320 Well, it seems like Apple has put a lot of 226 00:10:53.320 --> 00:10:56.360 thought and effort into securing its operating systems. We've only 227 00:10:56.440 --> 00:10:58.720 just scratched the surface, and I'm already impressed by the 228 00:10:58.720 --> 00:11:01.759 complexity and depth of these security mechanisms, and. 229 00:11:01.720 --> 00:11:04.559 We've only just begun. There's much more to explore in 230 00:11:04.600 --> 00:11:07.039 the world of Apple security, so stay tuned for more 231 00:11:07.039 --> 00:11:08.759 insights as we continue our deep dive. 232 00:11:09.039 --> 00:11:12.159 Welcome back. It's amazing to think about all the security 233 00:11:12.200 --> 00:11:15.200 measures working behind the scenes every time we use our 234 00:11:15.200 --> 00:11:18.399 Apple devices. It's like having a whole team of digital 235 00:11:18.440 --> 00:11:21.080 bodyguards protecting us from unseen threats. 236 00:11:21.320 --> 00:11:24.559 And like any good security team, they've got multiple layers 237 00:11:24.600 --> 00:11:27.519 of defense. It's not just about keeping the bad guys out, 238 00:11:27.720 --> 00:11:30.639 it's also about limiting the damage they can do if 239 00:11:30.639 --> 00:11:32.159 they manage to slip through the cracks. 240 00:11:32.240 --> 00:11:34.919 Okay, that makes sense. So what kind of damage control 241 00:11:34.919 --> 00:11:37.039 measures are we talking about here? What else does Apple 242 00:11:37.080 --> 00:11:37.960 have up its sleeve? 243 00:11:38.279 --> 00:11:43.440 Well, let's talk about software restrictions, specifically, how even Apple's 244 00:11:43.519 --> 00:11:45.840 own apps have limits on what they can do. 245 00:11:46.159 --> 00:11:48.200 Wait a minute, even Apple's apps. I thought they had 246 00:11:48.240 --> 00:11:49.480 free rein of the system. 247 00:11:49.600 --> 00:11:53.559 Not quite. Even Apple recognizes that some operations are just 248 00:11:53.679 --> 00:11:56.279 too sensitive to allow unrestricted access. 249 00:11:56.320 --> 00:11:58.159 Like, what kind of things are we talking about? 250 00:11:58.200 --> 00:12:01.440 Think about accessing your keychain, where all your passwords and 251 00:12:01.519 --> 00:12:06.080 sensitive data are stored, or modifying critical system files. Those 252 00:12:06.080 --> 00:12:08.399 are actions that shouldn't be taken lightly. 253 00:12:08.360 --> 00:12:10.360 Right, That makes sense. You don't want just any app 254 00:12:10.399 --> 00:12:12.799 messing around with that kind of stuff. So how does 255 00:12:12.840 --> 00:12:14.440 macOS keep things in check? 256 00:12:14.919 --> 00:12:19.240 It uses something called the authorizations mechanism, which relies on 257 00:12:19.440 --> 00:12:22.240 you guessed it, another Scoli database. 258 00:12:21.919 --> 00:12:24.639 Cerusly, another Scualae database. They seem to be everywhere. 259 00:12:24.759 --> 00:12:27.440 They're just really good at what they do. This particular 260 00:12:27.519 --> 00:12:31.879 database stores rules that is, termine which operations require special 261 00:12:31.919 --> 00:12:35.519 authorization and under what conditions that authorization can be granted. 262 00:12:35.600 --> 00:12:38.519 So it's like a set of bylaws for apps, defining 263 00:12:38.519 --> 00:12:40.399 what they can and can't do exactly. 264 00:12:40.840 --> 00:12:43.639 And what's really interesting is that you can actually examine 265 00:12:43.679 --> 00:12:46.879 this authorization database yourself using the command line. 266 00:12:46.919 --> 00:12:49.759 Wait, you mean we can see the actual rules that 267 00:12:49.840 --> 00:12:51.039 govern what apps can do? 268 00:12:51.240 --> 00:12:53.600 You can. The book even gives examples of how to 269 00:12:53.639 --> 00:12:57.639 extract specific rules from the database using this quad three tool. 270 00:12:57.960 --> 00:13:00.720 It's a fascinating way to see how these restrictions are implemented. 271 00:13:01.159 --> 00:13:03.279 I can see how that would be useful for developers 272 00:13:03.279 --> 00:13:06.799 and security researchers. But is there any risk in making 273 00:13:06.840 --> 00:13:11.279 this information accessible. Could someone with bad intentions manipulate these rules? 274 00:13:11.399 --> 00:13:15.120 It's definitely a possibility, although Apple has implemented various safeguards 275 00:13:15.159 --> 00:13:18.080 to make it more difficult. But it highlights the constant 276 00:13:18.159 --> 00:13:22.159 cat and mouse game between security and those who seek 277 00:13:22.200 --> 00:13:23.000 to circumvent it. 278 00:13:23.240 --> 00:13:25.480 Right, because if you can change the rules of the game, 279 00:13:26.120 --> 00:13:28.840 you can potentially change the outcome exactly. 280 00:13:29.360 --> 00:13:32.080 And that brings us to another important player in Apple's 281 00:13:32.080 --> 00:13:34.279 security lineup, Gatekeepers. 282 00:13:34.559 --> 00:13:38.399 Gatekeepers is that like a bouncer for apps, checking IDs 283 00:13:38.440 --> 00:13:38.960 at the door. 284 00:13:39.360 --> 00:13:41.879 You could say that it's Apple's first line of defense 285 00:13:41.919 --> 00:13:46.039 against untrusted software. When you download an application from the Internet, 286 00:13:46.519 --> 00:13:49.080 Gatekeeper steps in to verify its credentials. 287 00:13:49.120 --> 00:13:52.039 Credentials, so is it looking for a code signature like 288 00:13:52.039 --> 00:13:53.559 we talked about earlier, that's. 289 00:13:53.399 --> 00:13:55.799 A big part of it. If an app isn't signed 290 00:13:55.840 --> 00:13:59.440 by a trusted developer, Gatekeepers will raise a red flag 291 00:14:00.080 --> 00:14:02.919 and prevent you from running it without explicit confirmation. 292 00:14:03.320 --> 00:14:06.360 I've definitely seen those warnings pop up before, especially when 293 00:14:06.360 --> 00:14:08.679 I try to run something I've downloaded from a less 294 00:14:08.679 --> 00:14:09.639 and reputable source. 295 00:14:09.960 --> 00:14:13.440 That's exactly when Gatekeeper is doing its job, protecting you 296 00:14:13.519 --> 00:14:17.200 from potentially a harmful software. But you might be wondering 297 00:14:17.240 --> 00:14:20.279 how Gatekeeper knows that a file was downloaded from the 298 00:14:20.279 --> 00:14:21.360 Internet in the first place. 299 00:14:21.519 --> 00:14:24.000 Yeah, how does it tell the difference between something I 300 00:14:24.039 --> 00:14:26.399 downloaded and something that's always been on my computer? 301 00:14:26.799 --> 00:14:30.200 It uses a clever trick called quarantine attributes. When you 302 00:14:30.240 --> 00:14:34.240 download a file, the system automatically tags it with these attributes, 303 00:14:34.799 --> 00:14:37.039 marking it as potentially untrusted. 304 00:14:37.200 --> 00:14:39.759 So it's like a little sticky note that says handle. 305 00:14:39.440 --> 00:14:42.840 With care exactly. And what's really interesting is that you 306 00:14:42.879 --> 00:14:46.679 can actually manipulate these quarantine attributes yourself using the zatri 307 00:14:46.759 --> 00:14:47.559 command line tool. 308 00:14:47.600 --> 00:14:50.039 Hold on, are you saying I could potentially remove these 309 00:14:50.080 --> 00:14:54.200 attributes and trick Gatekeepers into thinking a downloaded file is safe. 310 00:14:54.240 --> 00:14:57.840 It's possible, but Apple has implemented additional measures to make 311 00:14:57.879 --> 00:15:01.120 it more difficult. For example, Keeper's also checks for a 312 00:15:01.159 --> 00:15:06.440 special extended attribute called comm dot apple dot quarantine, which 313 00:15:06.440 --> 00:15:09.000 stores more detailed information about the file's origin. 314 00:15:09.200 --> 00:15:12.720 So even if you remove the basic quarantine attributes, there's 315 00:15:12.759 --> 00:15:15.399 still this extra layer of information that could trip you 316 00:15:15.480 --> 00:15:16.279 up exactly. 317 00:15:16.480 --> 00:15:20.080 Apple clearly thought about this and built in some redundancy 318 00:15:20.559 --> 00:15:23.679 to make it harder for attackers to circumvent gatekeepers. 319 00:15:24.039 --> 00:15:28.240 Speaking of redundancy, the book mentions something called lib quarantine 320 00:15:28.759 --> 00:15:33.360 and a rather oddly named system demon called SIPOILCID. What 321 00:15:33.399 --> 00:15:35.200 do those have to do with gatekeeper good catch? 322 00:15:35.799 --> 00:15:40.279 Lib quarantine is basically the toolbox for managing these quarantine attributes. 323 00:15:40.679 --> 00:15:43.200 It provides the functions that apps can use to interact 324 00:15:43.200 --> 00:15:43.960 with these flags. 325 00:15:44.000 --> 00:15:46.360 So it's the behind the scenes worker bee that makes 326 00:15:46.399 --> 00:15:49.879 the whole quarantine system tick. And what about sipoil sid. 327 00:15:49.679 --> 00:15:52.679 That's the enforcer. Sipoil said, is a system demon that 328 00:15:52.759 --> 00:15:56.039 runs in the background and constantly monitors for new files 329 00:15:56.039 --> 00:15:56.679 and downloads. 330 00:15:56.759 --> 00:15:59.919 So it's like a digital security guard patrolling the system, 331 00:16:00.159 --> 00:16:02.879 making sure nothing suspicious gets through exactly. 332 00:16:02.919 --> 00:16:06.000 It works in conjunction with other components like the kernel 333 00:16:06.039 --> 00:16:09.879 and the authorization database to enforce gatekeepers policies. 334 00:16:10.000 --> 00:16:12.360 Wow, it's amazing how much is going on behava scenes 335 00:16:12.399 --> 00:16:15.159 to keep our macs safe from harm. But I'm sensing 336 00:16:15.200 --> 00:16:18.679 a theme here. Apple seems to really like this layered 337 00:16:18.720 --> 00:16:19.960 approach to security. 338 00:16:20.039 --> 00:16:22.799 You're absolutely right, it's all about defense and depth. Yeah, 339 00:16:22.960 --> 00:16:26.759 no single mechanism is perfect, so they combine multiple layers 340 00:16:27.120 --> 00:16:30.000 to make it as difficult as possible for attackers to 341 00:16:30.200 --> 00:16:31.480 exploit any weaknesses. 342 00:16:31.960 --> 00:16:33.919 And that brings us to what might be the most 343 00:16:33.960 --> 00:16:36.080 important layer of all sandboxing. 344 00:16:36.159 --> 00:16:40.519 Ah. Yes, sandboxing. It's one of Apple's most powerful security 345 00:16:40.519 --> 00:16:44.919 mechanisms and a cornerstone of both mac os and iOS. 346 00:16:45.159 --> 00:16:47.799 I've heard the term before, but I'm not exactly sure 347 00:16:47.840 --> 00:16:49.480 what it means. Can you break it down for me? 348 00:16:49.799 --> 00:16:53.000 Think of sandboxing like a playpen for apps. Instead of 349 00:16:53.080 --> 00:16:55.360 letting an app have free rein of the system, it 350 00:16:55.440 --> 00:16:58.440 confines it to a specific area with limited permissions. 351 00:16:58.639 --> 00:17:02.039 So even if an app is militia or compromised, sandboxing 352 00:17:02.080 --> 00:17:04.079 prevents it from doing too much damage. 353 00:17:04.160 --> 00:17:07.240 That's the idea. It's like containing a potentially dangerous experiment 354 00:17:07.279 --> 00:17:08.359 to a controlled environment. 355 00:17:08.519 --> 00:17:10.400 Okay, I'm starting to see how this fits into the 356 00:17:10.480 --> 00:17:14.119 layered security model, But how does sandboxing actually work? What's 357 00:17:14.119 --> 00:17:15.119 the magic behind it? 358 00:17:15.440 --> 00:17:19.279 The magic, or rather the technology behind it, is AMAC 359 00:17:19.799 --> 00:17:24.000 the mandatory Access control framework we discussed earlier. Each sandboxed 360 00:17:24.000 --> 00:17:27.160 app is given a set of Mac labels and policies 361 00:17:27.799 --> 00:17:29.640 that define what it's allowed to do. 362 00:17:29.839 --> 00:17:32.640 AH. So it's back to those labels and policies, but 363 00:17:32.720 --> 00:17:34.839 this time they're being used to restrict what an app 364 00:17:34.880 --> 00:17:38.000 can do, rather than just controlling access to files. 365 00:17:37.680 --> 00:17:41.480 Exactly, and the sandboxes evolved significantly over the years. In 366 00:17:41.519 --> 00:17:43.640 the early days, it used a blacklist approach. 367 00:17:43.960 --> 00:17:47.279 Blacklist meaning they had a list of specific things that 368 00:17:47.319 --> 00:17:50.119 apps weren't allowed to do and everything else was permitted. 369 00:17:50.279 --> 00:17:52.839 You got it. But this approach proved to be too 370 00:17:52.960 --> 00:17:57.279 limiting and difficult to maintain. As the threat landscape changed, 371 00:17:57.559 --> 00:18:00.799 Apple realized they needed a more flexible and robut. 372 00:18:00.279 --> 00:18:03.160 So they switched to a whitelist approach. 373 00:18:03.279 --> 00:18:06.799 Precisely, instead of focusing on what apps can't do, they 374 00:18:06.799 --> 00:18:10.160 shifted to defining what apps can do. This means everything 375 00:18:10.200 --> 00:18:14.200 is forbidden by default unless explicitly allowed by the sandbox rules. 376 00:18:14.240 --> 00:18:16.440 That sounds much more secure, but I imagine it also 377 00:18:16.480 --> 00:18:18.240 makes things more complicated for developers. 378 00:18:18.559 --> 00:18:21.200 It does, but it's a trade off worth making for 379 00:18:21.240 --> 00:18:24.599 the increased security and to make things easier for developers, 380 00:18:25.079 --> 00:18:27.559 Apple introduced sandbox profiles. 381 00:18:27.640 --> 00:18:29.519 Sandbox profiles what are those? 382 00:18:29.599 --> 00:18:33.759 They're essentially configuration files that define the allowed actions for 383 00:18:33.799 --> 00:18:34.720 a specific app. 384 00:18:34.839 --> 00:18:38.240 So instead of having to manually specify every single permission, 385 00:18:38.519 --> 00:18:41.480 developers can just use a predefined profile that matches their 386 00:18:41.480 --> 00:18:42.599 apps needs. 387 00:18:42.480 --> 00:18:45.440 Exactly, and you can actually inspect these profiles. The book 388 00:18:45.440 --> 00:18:47.519 gives examples of how to use a command line tool 389 00:18:47.599 --> 00:18:49.400 called ASTI to do just that. 390 00:18:49.759 --> 00:18:52.759 Ask TI another cryptogachronym, I take it. 391 00:18:52.759 --> 00:18:56.519 It stands for Apple Sandbox command Line Interface. It's a 392 00:18:56.559 --> 00:18:59.559 powerful tool for developers and security researchers. 393 00:18:59.079 --> 00:19:02.720 Alike can peek into these profiles and see exactly what 394 00:19:02.759 --> 00:19:03.799 an app is allowed to do. 395 00:19:03.880 --> 00:19:06.559 You can and you can even modify those permissions for 396 00:19:06.599 --> 00:19:10.359 testing purposes, although as always, we strongly advise against making 397 00:19:10.400 --> 00:19:12.640 any unauthorized changes to your system. 398 00:19:12.440 --> 00:19:15.359 Right We don't want to accidentally unleash any digital monsters. 399 00:19:15.720 --> 00:19:18.920 But it's fascinating to see how much control and transparency 400 00:19:18.960 --> 00:19:21.200 Apple provides with its sandboxing system. 401 00:19:21.440 --> 00:19:23.759