跟读练习: STOP Running Code On Your Computer - 通过视频学习英语口语

Every single time you install a dependency, run an extension in your code editor, run the build process for an app you're working on, or run the app itself,

you are running code on your computer that you did not write.

And that code has access to more than just your project directory.

And just as an example, I have this simple Python script here, and I'm running this with no extra privileges.

All it does is scan the file system.

And with one single command, it has every cookie and session data from Firefox and Chrome,

Slack and Discord, as well as access to my NPM token and SSH private keys, basically everything on my machine.

So when an attacker's code gets onto your machine, it has access to pretty much everything.

And attacker code can come from anywhere.

But what we're probably most familiar with is supply chain attacks.

Essentially, a package on some public repository gets compromised.

And then when end users install that package, they get compromised as well.

But it's not as simple as, oh, I don't have any vulnerable dependencies.

Why should I care or why does this matter to me, your dependencies have dependencies and your dependencies dependencies have dependencies.

These are known as transitive dependencies and it's very possible that even though you're not directly dependent on some vulnerable package,

their dependencies might be the victim of some sort of supply chain attack and that's how these things spread.

These are real incidents

that have increased in their occurrence over the past couple of years as more

and more attackers leverage these developer ecosystems

that we all thought we could trust the main question isn't really if you'll install something compromised, it's when.

And so from there, the question becomes, what can that code do?

And that's what we're going to talk about in this video.

I'm going to give you a basic primer on security concepts, how running code works, how what it has access to, and how you can limit that access.

Because that's really the basic concept that any sort of isolation mechanism or agent container allows us to do, which is prevent the blast radius.

If something gets compromised, you want to make sure that it doesn't have access to everything.

So let's dive in.

My name is CJ.

Welcome to Syntax.

Now, first, let's talk about the blast radius, which is if something goes wrong, what can it do or what does it have access to?

And so if we consider your development machine today, let's say you run all of your projects locally.

Everything is happening just directly on your machine.

If something gets compromised or goes rogue, it has access to everything on your computer.

It has access to your email, it can check if you're logged into your bank, it can access any sort of password vaults, SSH keys, ENV files, essentially anything on your computer

an attacker would potentially have access to if you are a victim of their attack.

And so the fix is easy.

Never run untrusted code on a machine that has anything that you care about.

So we're essentially going to shrink that blast radius to zero by isolating code execution from your credentials and accounts.

So the answer to this is isolation.

When you're running a program, instead of giving it access to your entire computer, we can limit that access.

And there are four security concepts you can apply to any one of those isolation levels

that we'll talk about in the next section.

And the first security concept is the principle of least privilege.

Give it only access to what it needs.

So maybe your program needs to talk to some hosted database, but will it work with read-only credentials?

If so, use those.

That way, if those credentials are compromised, they can't write anything to the database.

Also, don't run code on the same system

that has stored credentials for other services or other unrelated things to the project at hand.

Now, number two, the next security concept is network filtering or egress filtering.

That is, it can't phone home if it can't make requests.

Now, one of the ways attackers take advantage of credential leaks like this are, potentially, if they can run code on your system, they will just send all of the secret data that they found off to some remote computer.

And then maybe later, they can go look and try to use those credentials in certain places.

But if your code is running in an environment that only has access to specific network resources, like specific servers, specific databases, or specific package manager registries,

and not the entire internet, that makes it much harder for an attacker to exfiltrate that data to some remote server or some remote system.

Now, number three, our next security concept is ephemeral environments, that is temporary environments.

Essentially, we can use the environment, destroy it, and then nothing lingers around.

So if there is anything compromised, it's completely gone the moment we delete that isolated system.

And number four, the last one is defense in depth.

So no single layer of protection is enough.

We essentially stack them so we get more security guarantees with these layers of security.

So isolation alone isn't going to prevent that one isolated thing from being compromised.

We can do these other things like only mount the secrets

that it has access to or only give it certain network access to limit

that blast radius if that one isolated environment does become compromised.

Now, how do we actually do all of this?

I'm going to give you five ranks on the ladder of isolation you can choose from.

And level one is containers.

Now, if you're in the world of development, you've probably heard of Docker and you may not be using it yet, but this is one of the easiest ways to get up and going with an isolated environment.

You essentially define a configuration that says what operating system you're running, what dependencies does it have, what steps need to happen in order to set this container up to be ready for your project.

And then the container runtime uses that configuration to automatically spin up a brand new environment that has everything ready to go.

Now, containerization is operating system level virtualization.

Essentially, every container that gets created gets its own set of processes that it can access, its own file system, and its own users.

But each these containers shares the host operating system's kernel.

So this is a basic level of isolation because if compromised code is able to break out of that container,

it immediately has access to the host operating system and in turn would have access to all of your files.

Now while container breakouts are rare, they do happen and so there are other levels of isolation that we'll talk about soon.

Now related to containers is the dev container specification.

Essentially you define a container configuration specific to the development environment that you need for your project,

And then there are various code editors like VS Code or Zed that can then look at that configuration, spin up one or more containers, and automatically connect your editor instance to that running container.

Then any file changes you make are automatically synced, and any dependencies that got installed or editor extensions that ran or code that ran runs inside the container.

Now, this is a great way to share your development configuration with your team

and make it really easy for people to get up and going.

But like we mentioned, it's running in a container, which isn't necessarily the best type of isolation.

So that brings us to level two in our ladder of isolation, virtual machines.

Now, virtual machines are hardware level virtualization.

Essentially, every virtual machine that gets created has its own hard drive, its own RAM, and its own CPU.

And all of that is being shared from the host system.

So each virtual machine gets its own dedicated resources.

Now, virtual machines are typically more resource intensive and sometimes slower to start up than containers,

but they limit our exposure even more because breaking out of a virtual machine is a much harder technical feat.

And so if vulnerable code does somehow get onto those virtual machines, it's very unlikely that it'll be able to break out to the host operating system.

Now, there are a ton of different ways to get up and going with virtual machines, but one of the easiest ways is to use a program like UTM

if you're on macOS or VirtualBox if you're on Windows or Linux.

And this is just a GUI application you can use to create virtual machines.

Essentially, you can decide how much CPU they get, how much RAM they get.

You can then boot them to a specific Linux or Windows installer, and now you have a virtual machine running on your computer.

Applications like this are a good entry point, especially if you want to learn about Linux.

Even if you're on Windows or Mac OS, you can boot up a Linux virtual machine and then play around with it, and you don't even have to actually have a dedicated Linux machine.

Now, using GUI applications like this is a little more cumbersome

100

if you want to set it up for development because they're only scriptable or automatable in certain aspects.

101

And if you want to create reproducible environments, it's a little bit trickier to do with these GUI programs.

102

One of the more automated and scriptable ways of spinning up VMs is actually from Docker and it's called Docker Sandbox.

103

And it actually doesn't use containers.

104

It uses what is known as micro VMs.

105

And with one command, Docker Sandbox will spin up a virtual machine

106

that is linked to that one project directory that you're running the command in.

107

It has no access to other files on your system.

108

And Docker Sandbox takes that same configuration file that you would use with Docker containers.

109

So this is much easier to set up if if you want more reproducible dev environments for your sandboxes.

110

Now, another tool I came across is called Lima, and it essentially manages virtual machines for you, but from the command line.

111

And there's also a tool called CoLima, which only works on Mac OS and Linux, but it's essentially a wrapper on top of Lima that makes it

112

so that you can use your existing Docker configuration files to spin up virtual machines with Lima.

113

Now let's move on to level three of separation, full separation.

114

Essentially, you have an entirely separate machine for your development workflows.

115

Now, you could go fully custom and rent a VPS or virtual private server, or even rent a dedicated machine from some cloud hosting service, and then set up that machine as your development machine.

116

And then anytime you need to do development work, you SSH into that machine.

117

And that means if that machine ever gets compromised, it's not your computer, all of it is in the cloud.

118

Now, just like all the levels of security that we talked about, if you have a big single dedicated development machine in the cloud, you're not necessarily isolating your projects from each other.

119

And so if you have multiple projects with multiple credentials, you're not really adhering to the principle of least privilege for all of the apps

120

that are running on that development machine in the cloud.

121

So in theory, you could actually combine this with level two separation, where you actually spin up virtual machines on that machine you have in the cloud.

122

And then you basically have three levels of separation between you and the machine that that code is actually running on.

123

Now, you could also go the more opinionated route and use something like GitHub Codespaces.

124

You can essentially spin up a Codespace for any one of your projects on GitHub.

125

And this gives you a machine running in the cloud that only has access to that one project.

126

There are also self-hosted alternatives like coder.com, and you can essentially run this on your own VPS, but you get a more streamlined interface where you can define what type of environment each project needs

127

that you need to spin up and

128

that brings us to level four on the ladder of isolation

129

which i'll label as paranoid which is potentially justified

130

and these scenarios all try to add as much separation between your computer with all of your secrets

131

and everything you care about and the actual running code.

132

And the first is just a separate laptop.

133

Some of us potentially have old laptops we're not using anymore.

134

And you might be surprised how performant some of these custom Linux distributions have gotten in terms of older hardware.

135

And so I actually have one of these in my home lab.

136

It's just an old ThinkPad running CacheOS, and I use it as a development machine.

137

So it's totally separate from my computer, but it's in my house.

138

It's not even in the cloud.

139

And so I'm able to run all of my development workflows that I need, even on some of the older specs.

140

And to get even more paranoid than that, you might actually use a live operating system.

141

So this is used a lot by hackers or people

142

that don't want to have any trace of anything they've done on a computer.

143

They essentially use a live operating system like Tails OS, or you could even boot into a live USB that has Ubuntu on it, and you do all of your development work there.

144

And then the moment you shut down that laptop, it doesn't save anything because it was just running in that live USB environment.

145

Now, this seems like a really cumbersome way to do some development in my opinion, but it's also totally possible to do.

146

And because these are essentially ephemeral boots, every time you boot up, it's a brand new, fresh operating system.

147

You don't have any secrets or anything that could be extracted by malicious code.

148

And finally, this is hardcore tenfoil hat mode.

149

You could use an air-gapped machine.

150

That is, go into a room, unplug the literal Wi-Fi board from your laptop, and do all of your development work there.

151

And that way, if anything is compromised, it can't exfiltrate that data anywhere because there's no way for it to actually reach the internet.

152

Now, there could be some secret spy device nearby that's actually listening to the sound

153

that your hard drive is making or the sound that your keyboard makes when you're typing.

154

And it could exfiltrate all of that data somewhere else, but we're not going to go there.

155

So these are the five levels of isolation.

156

And if you really want to prevent yourself from being the victim of the next supply chain attack, you should be doing at least level one, if not level two.

157

And combine these levels with the security concepts that we covered at the beginning, including the principle of least privilege.

158

That is, give these isolated environments only access to the credentials that they need and nothing more.

159

And every one of those levels of isolation I talked about has some sort of mechanism for only mounting

160

or sharing a specific directory or specific files and not sharing your entire host file system.

161

And with that, you should also do egress filtering.

162

That is, limit the network resources that any one of these isolated environments has access to.

163

Because if they do get compromised, they potentially won't be able to reach out to an attacker server or exfiltrate your data to an attacker's remote host. And

164

And every one of these isolation mechanisms supports firewalls

165

or operating system level network blocks

166

that can essentially lock down these isolated environments to only have access to the network resources that they need access to.

167

And of course, to bring it all together, defense in depth.

168

Combine all of these various security mechanisms with an isolation mechanism to reduce your overall blast radius if you do become compromised.

169

So that's all I got for you in this one.

170

If you're using any of the tools I mentioned or have suggestions for other tools that people could use, let us know down in the comments.

171

And if you have any questions about setting any of this stuff up, let us know in the comments as well.

172

All right, stay safe out there.

173

I'll see you in the next one.

什么是跟读法？

跟读法 (Shadowing) 是一种有科学依据的语言学习技巧，最初开发用于专业口译员的培训，并由多语言者Alexander Arguelles博士普及。这个方法简单而强大：您在听英语母语原声的同时立即大声重复——就像是一个延迟1-2秒紧跟说话者的影子。与被动听力或语法练习不同，跟读法强迫您的大脑和口腔肌肉同时处理并模仿真实的讲话模式。研究表明它能显着提高发音准确性，语调，节奏，连读，听力理解和口语流利度——使其成为雅思口语备考和真实英语交流最有效的方法之一。

跟读练习: STOP Running Code On Your Computer - 通过视频学习英语口语

关于本课

什么是跟读法？