0 00:00:00,000 --> 00:00:30,000 Dear viewer, these subtitles were generated by a machine via the service Trint and therefore are (very) buggy. If you are capable, please help us to create good quality subtitles: https://c3subtitles.de/talk/542 Thanks! 1 00:00:09,770 --> 00:00:11,839 Now we have Ed Scouten, 2 00:00:11,840 --> 00:00:14,699 who's working on Cloud Abai, 3 00:00:14,700 --> 00:00:16,999 a way to make this a lot more easier 4 00:00:17,000 --> 00:00:19,369 by building a sandboxing 5 00:00:19,370 --> 00:00:21,469 friendly POSIX runtime environment. 6 00:00:21,470 --> 00:00:23,359 Please give him a warm round of applause. 7 00:00:30,650 --> 00:00:32,809 Thank you. Thank you. 8 00:00:32,810 --> 00:00:34,699 How it works. Yeah, good. 9 00:00:34,700 --> 00:00:36,589 So it's actually nice to see, like, such 10 00:00:36,590 --> 00:00:37,759 a full room over here. 11 00:00:37,760 --> 00:00:39,829 There's only like 10 or 20 spare 12 00:00:39,830 --> 00:00:40,909 seats left. 13 00:00:40,910 --> 00:00:43,039 The last time I gave this talk in Germany 14 00:00:43,040 --> 00:00:45,319 was back at Foxconn, which was in 15 00:00:45,320 --> 00:00:47,729 September, I think, conference 16 00:00:47,730 --> 00:00:50,059 that's in a place close to bomb. 17 00:00:50,060 --> 00:00:52,129 And what was a bit of a 18 00:00:52,130 --> 00:00:54,109 shame was that they planned my talk right 19 00:00:54,110 --> 00:00:56,209 at the end of the first day, right 20 00:00:56,210 --> 00:00:57,559 at around the time that they started 21 00:00:57,560 --> 00:01:00,529 firing up the barbecue, which 22 00:01:00,530 --> 00:01:02,629 which meant that, like, I only had 10 or 23 00:01:02,630 --> 00:01:04,039 20 people attending my talk. 24 00:01:04,040 --> 00:01:05,809 So it's really the opposite experience of 25 00:01:05,810 --> 00:01:06,769 what I'm having over here. 26 00:01:06,770 --> 00:01:08,899 So I'm awake. 27 00:01:08,900 --> 00:01:10,759 My laptop turned itself off. 28 00:01:10,760 --> 00:01:11,659 Now it works again. 29 00:01:11,660 --> 00:01:13,729 Yeah. So before I 30 00:01:13,730 --> 00:01:15,409 start to talk, let me first sort of 31 00:01:15,410 --> 00:01:17,569 introduce myself quickly. 32 00:01:17,570 --> 00:01:18,679 My name's Scouter. 33 00:01:18,680 --> 00:01:20,929 I'm an open source hacker from 34 00:01:20,930 --> 00:01:23,029 the Netherlands back 35 00:01:23,030 --> 00:01:24,139 in 2002. 36 00:01:24,140 --> 00:01:25,609 2000. Yeah, 2002. 37 00:01:25,610 --> 00:01:27,829 When I started studying, I became really 38 00:01:27,830 --> 00:01:29,719 interested in how open source operating 39 00:01:29,720 --> 00:01:30,889 systems worked. 40 00:01:30,890 --> 00:01:32,749 Before that, I was still a Windows user. 41 00:01:32,750 --> 00:01:35,209 But then I started using Linux and, 42 00:01:35,210 --> 00:01:37,279 um, a year or two years later, 43 00:01:37,280 --> 00:01:39,049 I also started using FreeBSD. 44 00:01:39,050 --> 00:01:41,329 I used OpenBSD for some time. 45 00:01:41,330 --> 00:01:43,399 Most of these sort of commonly 46 00:01:43,400 --> 00:01:44,989 used open source operating systems. 47 00:01:44,990 --> 00:01:47,059 I've even tried running them 48 00:01:47,060 --> 00:01:48,439 once. 49 00:01:48,440 --> 00:01:50,449 Some of them I liked a lot, some of them 50 00:01:50,450 --> 00:01:51,499 I didn't really like. 51 00:01:51,500 --> 00:01:53,659 But the ones that sort of stuck with 52 00:01:53,660 --> 00:01:55,459 is freebees the as you can see, my 53 00:01:55,460 --> 00:01:57,589 T-shirt and 54 00:01:57,590 --> 00:01:59,509 I also use Linux on the day to day basis 55 00:01:59,510 --> 00:02:00,510 as well. 56 00:02:01,280 --> 00:02:03,859 So back 57 00:02:03,860 --> 00:02:06,049 late last year, I 58 00:02:06,050 --> 00:02:08,359 actually lived in Germany and 59 00:02:08,360 --> 00:02:10,549 I had my day job where 60 00:02:10,550 --> 00:02:11,839 I did a lot of software making over 61 00:02:11,840 --> 00:02:14,239 there. But there was something that 62 00:02:14,240 --> 00:02:16,429 really sort of caused an itch 63 00:02:16,430 --> 00:02:18,289 that wasn't that I couldn't scratch, 64 00:02:20,300 --> 00:02:22,699 that I couldn't sort of fulfill at my 65 00:02:22,700 --> 00:02:24,229 previous employer, which is the reason 66 00:02:24,230 --> 00:02:25,969 why I left and decided to start my own 67 00:02:25,970 --> 00:02:28,189 small, small scale IT 68 00:02:28,190 --> 00:02:29,869 consulting company called Nuzzi, which is 69 00:02:29,870 --> 00:02:32,119 just Unix with byte ordering issues. 70 00:02:32,120 --> 00:02:33,349 So enough about me. 71 00:02:33,350 --> 00:02:35,089 Let's talk about cloud API, which is what 72 00:02:35,090 --> 00:02:37,369 I've been developing for the last year. 73 00:02:37,370 --> 00:02:38,599 And before I'm going to explain what 74 00:02:38,600 --> 00:02:40,999 Cloud API is, I'm first going to explain 75 00:02:41,000 --> 00:02:42,559 what I think is wrong with Unix. 76 00:02:42,560 --> 00:02:44,299 And lots of people have different 77 00:02:44,300 --> 00:02:46,099 opinions about what's wrong with Unix. 78 00:02:46,100 --> 00:02:48,259 So, you know, this is probably just 79 00:02:48,260 --> 00:02:49,999 bike sharing, trolling. 80 00:02:50,000 --> 00:02:51,169 You know, we'll see at the end of the 81 00:02:51,170 --> 00:02:52,669 talk during the Q&A whether you people 82 00:02:52,670 --> 00:02:54,049 agree or not. 83 00:02:54,050 --> 00:02:56,359 So even though UNIX 84 00:02:56,360 --> 00:02:57,769 is an awesome operating system that I've 85 00:02:57,770 --> 00:02:59,839 used for more than a decade now, there 86 00:02:59,840 --> 00:03:02,089 are like two issues that I've 87 00:03:02,090 --> 00:03:04,099 never really been solved, in my opinion. 88 00:03:04,100 --> 00:03:06,319 So to first of all, is that the system 89 00:03:06,320 --> 00:03:08,269 itself doesn't really stimulate you to 90 00:03:08,270 --> 00:03:10,039 run software in a secure fashion. 91 00:03:10,040 --> 00:03:11,479 And what I mean with that, I'll explain 92 00:03:11,480 --> 00:03:12,499 in a minute. 93 00:03:12,500 --> 00:03:14,269 And it also doesn't really stimulations 94 00:03:14,270 --> 00:03:16,309 right. Reusable, testable software, which 95 00:03:16,310 --> 00:03:18,680 I'll explain afterwards, so. 96 00:03:20,160 --> 00:03:22,109 Let's look at like a very simple use 97 00:03:22,110 --> 00:03:23,939 case, say you have like a Linux server 98 00:03:23,940 --> 00:03:25,529 running somewhere and you want to run a 99 00:03:25,530 --> 00:03:27,629 Web server on, it could be a patsy. 100 00:03:27,630 --> 00:03:28,649 It could be engine X. 101 00:03:28,650 --> 00:03:29,609 It doesn't really matter. 102 00:03:29,610 --> 00:03:31,799 Just some Web server. 103 00:03:31,800 --> 00:03:34,049 This Web server only needs to do like 104 00:03:34,050 --> 00:03:36,149 a handful number of things, just a really 105 00:03:36,150 --> 00:03:37,769 tiny number of things if you really think 106 00:03:37,770 --> 00:03:40,139 about it. So it needs to accept 107 00:03:40,140 --> 00:03:42,239 incoming TCP connections on 108 00:03:42,240 --> 00:03:43,889 which it will receive Hacia to be get 109 00:03:43,890 --> 00:03:46,169 requests and, you know, somehow process 110 00:03:46,170 --> 00:03:48,299 them. Maybe it needs to access some files 111 00:03:48,300 --> 00:03:50,519 on disk stored in some kind of directory. 112 00:03:50,520 --> 00:03:52,709 Maybe if there's like some kind of, 113 00:03:52,710 --> 00:03:54,779 you know, for example, a python or a 114 00:03:54,780 --> 00:03:56,879 B script in there that connects with some 115 00:03:56,880 --> 00:03:58,409 kind of database backend, it also needs 116 00:03:58,410 --> 00:04:00,059 to open a connection to that and then 117 00:04:00,060 --> 00:04:02,009 perform some transactions, computer 118 00:04:02,010 --> 00:04:03,599 responds and send that back across the 119 00:04:03,600 --> 00:04:05,099 DCP connection. 120 00:04:05,100 --> 00:04:07,229 So this is just really if you 121 00:04:07,230 --> 00:04:08,789 sort of look at all of the possible 122 00:04:08,790 --> 00:04:10,649 things that a UNIX program could do, this 123 00:04:10,650 --> 00:04:11,909 is just a really tiny 124 00:04:13,830 --> 00:04:15,389 amount of functionality. 125 00:04:15,390 --> 00:04:17,159 But what you see is once such a program 126 00:04:17,160 --> 00:04:19,049 is compromised, an attacker can basically 127 00:04:19,050 --> 00:04:21,659 just do anything that that user 128 00:04:21,660 --> 00:04:23,339 can do that the Web servers running is, 129 00:04:23,340 --> 00:04:24,989 which is quite a lot of stuff. 130 00:04:24,990 --> 00:04:26,549 So first of all, it could just create 131 00:04:26,550 --> 00:04:28,289 like a table of all the world readable 132 00:04:28,290 --> 00:04:29,279 data under slash. 133 00:04:29,280 --> 00:04:31,229 And, you know, if your file system 134 00:04:31,230 --> 00:04:33,509 permissions are set up in a correct way, 135 00:04:33,510 --> 00:04:35,549 then this might not be not be really 136 00:04:35,550 --> 00:04:37,649 damaging. But, you know, 137 00:04:37,650 --> 00:04:39,569 getting them set up for your entire file 138 00:04:39,570 --> 00:04:41,489 system correctly is in practice pretty 139 00:04:41,490 --> 00:04:43,679 hard. And also, what is really 140 00:04:43,680 --> 00:04:45,239 readable within your company might 141 00:04:45,240 --> 00:04:48,149 actually not be world readable, like 142 00:04:48,150 --> 00:04:49,709 for attackers on the other side of the 143 00:04:49,710 --> 00:04:50,699 Internet. 144 00:04:50,700 --> 00:04:52,559 So there are also some other nasty things 145 00:04:52,560 --> 00:04:53,909 that an attacker can do. 146 00:04:53,910 --> 00:04:55,379 So, for example, it can still invoke 147 00:04:55,380 --> 00:04:57,719 secuity utilities that are provided 148 00:04:57,720 --> 00:04:59,219 quite a large attack surface. 149 00:04:59,220 --> 00:05:01,169 So exploiting those programs can be, of 150 00:05:01,170 --> 00:05:03,359 course, you know, used by an attacker 151 00:05:03,360 --> 00:05:04,919 to gain even more privileges. 152 00:05:04,920 --> 00:05:06,299 And even if that's not the case, an 153 00:05:06,300 --> 00:05:07,919 attacker can still do some really nasty 154 00:05:07,920 --> 00:05:10,109 things. So say an 155 00:05:10,110 --> 00:05:11,759 attacker would manage to break into the 156 00:05:11,760 --> 00:05:13,649 Web server, install some kind of, you 157 00:05:13,650 --> 00:05:16,199 know, back connect 158 00:05:16,200 --> 00:05:17,939 surface where it can, you know, create 159 00:05:17,940 --> 00:05:19,829 login sessions on that system. 160 00:05:19,830 --> 00:05:21,839 Even if you would just update your Web 161 00:05:21,840 --> 00:05:23,309 server to a version that's no longer 162 00:05:23,310 --> 00:05:25,259 vulnerable to a certain exploit, an 163 00:05:25,260 --> 00:05:27,209 attacker could have just register.com job 164 00:05:27,210 --> 00:05:28,889 is that you don't just open it up every 165 00:05:28,890 --> 00:05:31,019 couple of minutes and be back in again. 166 00:05:31,020 --> 00:05:32,819 And even if all of those kinds of things, 167 00:05:32,820 --> 00:05:34,829 you know, accessing the file system is, 168 00:05:34,830 --> 00:05:37,109 you know, really well fenced off, 169 00:05:37,110 --> 00:05:38,609 an attacker can still turn the system 170 00:05:38,610 --> 00:05:40,769 into a botnet node, you know, and take 171 00:05:40,770 --> 00:05:42,809 part in Sindh flooding attacks, sending 172 00:05:42,810 --> 00:05:44,339 spam, that kind of stuff. 173 00:05:44,340 --> 00:05:46,229 So there's a huge disparity between what 174 00:05:46,230 --> 00:05:48,359 a program on UNIX and 175 00:05:48,360 --> 00:05:50,459 should be able to do and what it can do, 176 00:05:50,460 --> 00:05:52,529 because that's just how simple the Unix 177 00:05:52,530 --> 00:05:54,449 security model works. 178 00:05:54,450 --> 00:05:56,579 And you see that over 179 00:05:56,580 --> 00:05:58,979 time people have introduced 180 00:05:58,980 --> 00:06:00,689 sort of frameworks and new features 181 00:06:00,690 --> 00:06:02,909 through the kernel to sort of make 182 00:06:02,910 --> 00:06:04,049 it a lot better. 183 00:06:04,050 --> 00:06:06,359 And in my opinion, you can sort of divide 184 00:06:06,360 --> 00:06:07,469 them in two different categories. 185 00:06:07,470 --> 00:06:10,109 In the first one of them is is 186 00:06:10,110 --> 00:06:12,119 adding more access controls to the system 187 00:06:12,120 --> 00:06:14,729 so that the mindset being 188 00:06:14,730 --> 00:06:16,799 traditional UNIX permissions are sort 189 00:06:16,800 --> 00:06:18,689 of not granular enough, not precise 190 00:06:18,690 --> 00:06:21,299 enough. They can be expressed to 191 00:06:21,300 --> 00:06:22,979 cannot be used to express the actual 192 00:06:22,980 --> 00:06:24,629 restrictions that need to be placed on a 193 00:06:24,630 --> 00:06:26,009 Web server, for example. 194 00:06:26,010 --> 00:06:27,749 So we're going to extend that. 195 00:06:27,750 --> 00:06:29,819 And on Linux, you see 196 00:06:29,820 --> 00:06:31,139 that one of those frameworks is as e 197 00:06:31,140 --> 00:06:33,269 Linux, but another one is F armor and 198 00:06:33,270 --> 00:06:34,829 F armor allows you to create security 199 00:06:34,830 --> 00:06:36,329 policies for every application. 200 00:06:36,330 --> 00:06:38,369 You can create a sort of an additional 201 00:06:38,370 --> 00:06:41,219 separate security policy that's somewhat 202 00:06:41,220 --> 00:06:43,289 stored somewhere in EDC and 203 00:06:43,290 --> 00:06:44,699 that can be used to sort of restrict the 204 00:06:44,700 --> 00:06:46,079 application even further. 205 00:06:46,080 --> 00:06:47,429 But in my opinion, that's not a real 206 00:06:47,430 --> 00:06:48,779 solution to the problem, because what 207 00:06:48,780 --> 00:06:50,879 happens is that, you know, 208 00:06:50,880 --> 00:06:53,309 a software engineer just develops 209 00:06:53,310 --> 00:06:54,929 some kind of Web server, releases it, you 210 00:06:54,930 --> 00:06:56,999 know, froze the code over the fence to 211 00:06:57,000 --> 00:06:59,279 the people at the distributions. 212 00:06:59,280 --> 00:07:01,139 And there the people have to write these 213 00:07:02,280 --> 00:07:04,679 security policies and they actually 214 00:07:04,680 --> 00:07:06,449 don't sort of have to like the full 215 00:07:06,450 --> 00:07:07,859 understanding of how the application 216 00:07:07,860 --> 00:07:11,159 works. And in some cases, 217 00:07:11,160 --> 00:07:13,079 end users might actually need to modify 218 00:07:13,080 --> 00:07:14,549 these policies to get their application 219 00:07:14,550 --> 00:07:15,569 to work correctly. 220 00:07:15,570 --> 00:07:17,609 And I think that this is sort of not how 221 00:07:17,610 --> 00:07:19,409 it should be. It makes security a lot 222 00:07:19,410 --> 00:07:21,389 harder than it actually needs to be. 223 00:07:21,390 --> 00:07:23,489 And the problem is that, for 224 00:07:23,490 --> 00:07:25,589 example, going back to a 225 00:07:25,590 --> 00:07:27,359 Web server example, again, if you would 226 00:07:27,360 --> 00:07:29,399 change, for example, the root directory, 227 00:07:29,400 --> 00:07:31,799 if you observe in your configuration 228 00:07:31,800 --> 00:07:33,899 file, you also need to update it in 229 00:07:33,900 --> 00:07:35,939 your former security policy. 230 00:07:35,940 --> 00:07:38,009 Well, what happens is that some 231 00:07:38,010 --> 00:07:40,319 user tries to do this and for some reason 232 00:07:40,320 --> 00:07:42,239 it doesn't work anymore because he forgot 233 00:07:42,240 --> 00:07:44,099 to update the security policy. 234 00:07:44,100 --> 00:07:46,049 So then he Googles around a bit and then 235 00:07:46,050 --> 00:07:47,309 he just seems like, you know, this is 236 00:07:47,310 --> 00:07:48,269 caused by App Amahoro. 237 00:07:48,270 --> 00:07:50,489 I had the same thing on my Ubuntu system. 238 00:07:50,490 --> 00:07:51,839 So what does the user do? 239 00:07:51,840 --> 00:07:53,339 Objet remove app armor. 240 00:07:53,340 --> 00:07:54,539 Problem solved. 241 00:07:54,540 --> 00:07:56,909 So in 242 00:07:56,910 --> 00:07:59,759 my opinion, these kind of systems are 243 00:07:59,760 --> 00:08:00,689 they simply don't work. 244 00:08:00,690 --> 00:08:01,690 Right. 245 00:08:02,520 --> 00:08:04,019 And then there's a second class of 246 00:08:04,020 --> 00:08:06,689 systems and you know, 247 00:08:06,690 --> 00:08:08,759 over I've called them capability space, 248 00:08:08,760 --> 00:08:10,349 but they're not necessarily capabilities 249 00:08:10,350 --> 00:08:12,599 based. But, you know, just 250 00:08:12,600 --> 00:08:14,339 for the sake of argument, let's just, you 251 00:08:14,340 --> 00:08:16,409 know, frot of Secombe on 252 00:08:16,410 --> 00:08:18,059 Linux and capsicum just in one big 253 00:08:18,060 --> 00:08:19,419 bucket. I'm going. 254 00:08:19,420 --> 00:08:21,489 Explain how capsicum works and a bit more 255 00:08:21,490 --> 00:08:23,689 detail, because I shall see what 256 00:08:23,690 --> 00:08:26,619 we need to this knowledge later on, 257 00:08:26,620 --> 00:08:27,999 what happens with capsicum means that you 258 00:08:28,000 --> 00:08:29,709 just create your Web server like you 259 00:08:29,710 --> 00:08:31,809 Apache for engine starts up 260 00:08:31,810 --> 00:08:33,129 like your regular Unix process. 261 00:08:33,130 --> 00:08:34,899 And the first thing that it does is it 262 00:08:34,900 --> 00:08:36,668 passes the configuration files and the 263 00:08:36,669 --> 00:08:38,589 configuration files that list, for 264 00:08:38,590 --> 00:08:40,658 example, the IP addresses that the system 265 00:08:40,659 --> 00:08:42,939 needs to to listen on 266 00:08:42,940 --> 00:08:44,048 the path names of all the root 267 00:08:44,049 --> 00:08:46,179 directories and it and it 268 00:08:46,180 --> 00:08:48,429 sort of opens up all of those directories 269 00:08:48,430 --> 00:08:49,929 and all of those network connections that 270 00:08:49,930 --> 00:08:51,519 it actually needs. 271 00:08:51,520 --> 00:08:53,349 Then when that part is finished, it calls 272 00:08:53,350 --> 00:08:55,009 a system, a special system called called 273 00:08:55,010 --> 00:08:55,959 the cap enter. 274 00:08:55,960 --> 00:08:58,089 And this sort of Flagg's sort 275 00:08:58,090 --> 00:09:00,049 of an annotation bit in a kernel on the 276 00:09:00,050 --> 00:09:02,459 process to say that this process 277 00:09:02,460 --> 00:09:04,419 is now running in capability's mode. 278 00:09:04,420 --> 00:09:05,559 That's how it's called. 279 00:09:05,560 --> 00:09:08,169 And what happens is that, um, 280 00:09:08,170 --> 00:09:10,779 from that moment on, any sort of 281 00:09:10,780 --> 00:09:12,070 dangerous system call 282 00:09:13,360 --> 00:09:15,069 starts to return. The error code is not 283 00:09:15,070 --> 00:09:16,839 capable and to sort of explain what that 284 00:09:16,840 --> 00:09:19,059 means. So, for example, 285 00:09:19,060 --> 00:09:20,859 that network socket that we opened 286 00:09:20,860 --> 00:09:23,049 because it was sort of the IP address was 287 00:09:23,050 --> 00:09:24,879 mentioned in the configuration file, of 288 00:09:24,880 --> 00:09:26,709 course, it's safe to call except on that 289 00:09:26,710 --> 00:09:28,659 to accept incoming connections. 290 00:09:28,660 --> 00:09:30,879 You know, it's 291 00:09:30,880 --> 00:09:32,889 when you get one of those connections, 292 00:09:32,890 --> 00:09:34,539 it's safe to read and write on them, to 293 00:09:34,540 --> 00:09:36,279 sort of interact with the system on the 294 00:09:36,280 --> 00:09:38,349 other side. That's all safe. 295 00:09:38,350 --> 00:09:40,479 It's also safe to open files underneath 296 00:09:40,480 --> 00:09:42,249 directories that you've opened. 297 00:09:42,250 --> 00:09:44,349 But what's not safe is opening an 298 00:09:44,350 --> 00:09:46,979 arbitrary file on disk saying open 299 00:09:46,980 --> 00:09:49,179 slash slash 300 00:09:49,180 --> 00:09:50,829 password and writing stuff into it. 301 00:09:50,830 --> 00:09:52,329 For example, this is really not allowed, 302 00:09:52,330 --> 00:09:53,979 of course, you know, just opening any 303 00:09:53,980 --> 00:09:55,299 files, not allowed. 304 00:09:55,300 --> 00:09:56,799 And that's how capsicum works. 305 00:09:56,800 --> 00:09:59,229 It turns the system into a system 306 00:09:59,230 --> 00:10:01,179 that uses capability based security. 307 00:10:01,180 --> 00:10:03,249 And that basically means that there is no 308 00:10:03,250 --> 00:10:05,139 global state that a process has. 309 00:10:05,140 --> 00:10:06,909 But the process always sort of has a bag 310 00:10:06,910 --> 00:10:09,069 of capabilities file descriptors 311 00:10:09,070 --> 00:10:10,629 in this case that it can use to access 312 00:10:10,630 --> 00:10:12,339 resources on the system. 313 00:10:12,340 --> 00:10:14,289 And this is already used by quite a lot 314 00:10:14,290 --> 00:10:16,629 of applications on FreeBSD at least. 315 00:10:16,630 --> 00:10:19,059 So you see a list of programs, 316 00:10:19,060 --> 00:10:21,519 DHP, client paying, DCPI 317 00:10:21,520 --> 00:10:24,119 dump. Um, you know, TCAP 318 00:10:24,120 --> 00:10:25,239 is a really good example. 319 00:10:25,240 --> 00:10:26,529 If you think about it. The only thing 320 00:10:26,530 --> 00:10:28,119 that this program has to do is when it 321 00:10:28,120 --> 00:10:30,399 starts up, it has to open the Berkeley 322 00:10:30,400 --> 00:10:33,219 packet filter to capture network traffic. 323 00:10:33,220 --> 00:10:35,139 It needs to make sure that it has a file 324 00:10:35,140 --> 00:10:37,059 descriptor open to your terminal to 325 00:10:37,060 --> 00:10:38,889 actually write messages to it, you know, 326 00:10:38,890 --> 00:10:40,419 which packets were received. 327 00:10:40,420 --> 00:10:42,039 And when it has done that, it can safely 328 00:10:42,040 --> 00:10:43,329 call cap enter. 329 00:10:43,330 --> 00:10:45,639 And if an attacker somehow 330 00:10:45,640 --> 00:10:47,919 manages to trigger a buffer overflow 331 00:10:47,920 --> 00:10:50,439 inside of TGP dump, there is 332 00:10:50,440 --> 00:10:51,609 little to no risk at all. 333 00:10:51,610 --> 00:10:53,109 And this is actually far more likely than 334 00:10:53,110 --> 00:10:55,089 you think, because TCAP is full of all 335 00:10:55,090 --> 00:10:58,299 sorts of packet parsers, it can pass 336 00:10:58,300 --> 00:11:00,009 dozens, maybe hundreds of different 337 00:11:00,010 --> 00:11:02,019 network protocols and all sort of 338 00:11:02,020 --> 00:11:03,429 handwritten parcels to just 339 00:11:05,080 --> 00:11:06,789 find all of the specific interesting 340 00:11:06,790 --> 00:11:08,739 fields inside of all the packet headers. 341 00:11:08,740 --> 00:11:10,329 And there's a fair chance that it might 342 00:11:10,330 --> 00:11:12,489 be some buffer overflow intercept 343 00:11:12,490 --> 00:11:14,169 them. So what you can do is an attacker, 344 00:11:14,170 --> 00:11:16,149 as you can just sort of send all this 345 00:11:16,150 --> 00:11:18,099 random traffic across the network and 346 00:11:18,100 --> 00:11:20,109 just wait for a systems administrator to 347 00:11:20,110 --> 00:11:21,159 run TCP dump. 348 00:11:21,160 --> 00:11:22,659 And when that happens, you can actually 349 00:11:22,660 --> 00:11:24,849 just, you know, trigger a buffer overflow 350 00:11:24,850 --> 00:11:26,439 in a process that's running as the route 351 00:11:26,440 --> 00:11:28,419 user on the system because everyone runs 352 00:11:28,420 --> 00:11:29,829 Tsipi dumpers route. 353 00:11:29,830 --> 00:11:30,830 So 354 00:11:32,080 --> 00:11:33,609 this is a real good model for hardening 355 00:11:33,610 --> 00:11:35,349 all those those Unix utilities, in my 356 00:11:35,350 --> 00:11:37,929 opinion. Um, I really like it. 357 00:11:37,930 --> 00:11:40,089 So my 358 00:11:40,090 --> 00:11:41,439 experience is using capsicum. 359 00:11:41,440 --> 00:11:43,149 Late last year I started playing around 360 00:11:43,150 --> 00:11:45,339 with it and it really works as 361 00:11:45,340 --> 00:11:46,539 advertised. 362 00:11:46,540 --> 00:11:48,579 You know, the implementation of that is 363 00:11:48,580 --> 00:11:50,639 quite robust. And, you know, 364 00:11:50,640 --> 00:11:52,599 the design behind it is all right. 365 00:11:52,600 --> 00:11:54,759 But there is something 366 00:11:54,760 --> 00:11:56,259 that I noticed that really makes it hard 367 00:11:56,260 --> 00:11:58,689 to sort of use this at a larger scale, 368 00:11:58,690 --> 00:12:00,769 something that's larger than just being 369 00:12:00,770 --> 00:12:02,049 ought to be done, because those 370 00:12:02,050 --> 00:12:04,179 utilities, they are fairly small if 371 00:12:04,180 --> 00:12:06,009 you sort of look at your average UNIX 372 00:12:06,010 --> 00:12:07,210 system. So. 373 00:12:08,250 --> 00:12:10,679 My observation is the following code 374 00:12:10,680 --> 00:12:12,539 doesn't really like it if you suddenly 375 00:12:12,540 --> 00:12:14,429 start to disable functionality, that it 376 00:12:14,430 --> 00:12:16,499 depends on code. 377 00:12:16,500 --> 00:12:18,329 So so the best example that I could come 378 00:12:18,330 --> 00:12:19,619 up with, I'll first give you the best 379 00:12:19,620 --> 00:12:21,179 example that I ran into. 380 00:12:21,180 --> 00:12:23,069 There is this crypto libris to crypto 381 00:12:23,070 --> 00:12:25,079 libraries. Even I won't share the name, 382 00:12:25,080 --> 00:12:26,919 but what happens is that they try to open 383 00:12:26,920 --> 00:12:27,920 a referendum. 384 00:12:28,980 --> 00:12:31,079 And what do you do if that fails? 385 00:12:31,080 --> 00:12:32,519 Do you give an error message or do you 386 00:12:32,520 --> 00:12:33,809 terminate? 387 00:12:33,810 --> 00:12:35,249 No, not really. You actually just run, 388 00:12:35,250 --> 00:12:37,379 get time of day and then get the 389 00:12:37,380 --> 00:12:39,089 user I.D. or something like that. 390 00:12:39,090 --> 00:12:40,799 And then just use that as your initial 391 00:12:40,800 --> 00:12:42,179 state for the random number generator 392 00:12:42,180 --> 00:12:44,339 because, you know, the time is random 393 00:12:44,340 --> 00:12:45,509 enough. 394 00:12:45,510 --> 00:12:46,510 So 395 00:12:48,120 --> 00:12:49,679 that's actually pretty bad. So if you're 396 00:12:49,680 --> 00:12:51,059 not using capsicum, this code is 397 00:12:51,060 --> 00:12:53,309 completely safe because opening random 398 00:12:53,310 --> 00:12:54,989 always works. 399 00:12:54,990 --> 00:12:56,969 But as soon as you go cap enter, then it 400 00:12:56,970 --> 00:12:58,349 no longer works and you go through a 401 00:12:58,350 --> 00:12:59,789 different code baff that was sort of 402 00:12:59,790 --> 00:13:02,069 never exposed before on the regular 403 00:13:02,070 --> 00:13:03,389 Unix system and you end up with just 404 00:13:03,390 --> 00:13:05,909 completely unsafe setup. 405 00:13:05,910 --> 00:13:08,369 Now there's also some other 406 00:13:08,370 --> 00:13:10,319 annoying things that I ran into. 407 00:13:10,320 --> 00:13:12,630 So for example, time zones, 408 00:13:14,100 --> 00:13:15,719 if your program starts up and you call 409 00:13:15,720 --> 00:13:17,909 QEP, enter and then run, get time, sorry, 410 00:13:17,910 --> 00:13:20,219 local time, it uses UTC 411 00:13:20,220 --> 00:13:21,119 as your time zone. 412 00:13:21,120 --> 00:13:23,249 The reason for it is it can no longer 413 00:13:23,250 --> 00:13:25,649 exist EDC local time. 414 00:13:25,650 --> 00:13:27,749 But if you call local time at least 415 00:13:27,750 --> 00:13:29,789 once before calling QEP enter, it does 416 00:13:29,790 --> 00:13:31,109 use the local time zone. 417 00:13:31,110 --> 00:13:33,119 The same holds for localization. 418 00:13:33,120 --> 00:13:34,649 Once you call QEP enter, you can no 419 00:13:34,650 --> 00:13:36,869 longer do any conversions of 420 00:13:36,870 --> 00:13:38,459 pieces of text in different character 421 00:13:38,460 --> 00:13:39,809 sets. 422 00:13:39,810 --> 00:13:41,969 You know, it's just a real 423 00:13:41,970 --> 00:13:44,129 mess. So my observation is, 424 00:13:44,130 --> 00:13:45,130 if you just 425 00:13:46,230 --> 00:13:48,059 take like a really big Unix application, 426 00:13:48,060 --> 00:13:50,189 like affect your Engine X and you 427 00:13:50,190 --> 00:13:52,739 put a cap intercall somewhere, you know, 428 00:13:52,740 --> 00:13:54,539 somewhere a main, then the program will 429 00:13:54,540 --> 00:13:56,220 just explode in sort of 430 00:13:57,360 --> 00:13:59,849 ways that are really hard to cure. 431 00:13:59,850 --> 00:14:01,799 It's basically just, you know, you 432 00:14:01,800 --> 00:14:03,359 hacking on it for months just to get it 433 00:14:03,360 --> 00:14:05,219 working. There's no proper guided way of 434 00:14:05,220 --> 00:14:07,139 porting a larger application over. 435 00:14:07,140 --> 00:14:09,479 So what you see in practice is that 436 00:14:09,480 --> 00:14:11,579 smaller Unix applications and Fevzi, 437 00:14:11,580 --> 00:14:13,860 for example, are being ported over and 438 00:14:15,060 --> 00:14:17,039 sort of in-house maintained code, like, 439 00:14:17,040 --> 00:14:18,569 for example, the code that runs in your 440 00:14:18,570 --> 00:14:20,849 chrome tabs is being run in Secombe. 441 00:14:20,850 --> 00:14:23,159 But it's not as if most 442 00:14:23,160 --> 00:14:24,809 Unix applications make use of this. 443 00:14:24,810 --> 00:14:26,849 If you just run on your system, there's 444 00:14:26,850 --> 00:14:28,889 maybe only one or two processes on there. 445 00:14:28,890 --> 00:14:31,139 It actually uses Capsicum 446 00:14:31,140 --> 00:14:33,330 or Secombe BBF, so. 447 00:14:35,550 --> 00:14:36,939 That's really what I sort of dislike 448 00:14:36,940 --> 00:14:39,639 about capsicum and Secombe, 449 00:14:39,640 --> 00:14:41,769 they work for these really sort of 450 00:14:41,770 --> 00:14:44,289 you artificial or, well, 451 00:14:44,290 --> 00:14:46,059 self developed use cases, but not for 452 00:14:46,060 --> 00:14:48,309 sort of the the long tail 453 00:14:48,310 --> 00:14:49,310 of software. 454 00:14:50,500 --> 00:14:52,929 So a second problem that I 455 00:14:52,930 --> 00:14:55,329 have with unit security is that UNIX 456 00:14:55,330 --> 00:14:56,739 makes it really hard to just run 457 00:14:56,740 --> 00:14:58,509 untrusted programs directly on top of 458 00:14:58,510 --> 00:15:00,759 them. So if you just download a random 459 00:15:00,760 --> 00:15:02,799 ILF executable from the Internet and run, 460 00:15:02,800 --> 00:15:05,079 slash, run on it, or 461 00:15:05,080 --> 00:15:07,119 if it's cold, then you really mess up 462 00:15:07,120 --> 00:15:08,439 your system. Don't do this. 463 00:15:08,440 --> 00:15:09,610 I really wouldn't do this. 464 00:15:10,780 --> 00:15:12,819 Running it in jails, free BC jail, 465 00:15:12,820 --> 00:15:15,489 running it in Docker is a bit safer 466 00:15:15,490 --> 00:15:16,869 and the darker people are really 467 00:15:16,870 --> 00:15:18,399 convinced that docker's safe enough to 468 00:15:18,400 --> 00:15:19,809 run arbitrary executables. 469 00:15:19,810 --> 00:15:22,119 But I guess most 470 00:15:22,120 --> 00:15:23,709 security experts really wouldn't dare 471 00:15:23,710 --> 00:15:25,809 this etre running it inside of 472 00:15:25,810 --> 00:15:28,059 a VM. Is it safe 473 00:15:28,060 --> 00:15:29,379 while also not always. 474 00:15:29,380 --> 00:15:30,849 I guess there's likely to talk another 475 00:15:30,850 --> 00:15:32,859 talk at this conference that sort of 476 00:15:32,860 --> 00:15:35,199 debunks the the 477 00:15:35,200 --> 00:15:37,059 safety of systems like Sandack VM. 478 00:15:37,060 --> 00:15:39,339 But it's safe enough for most people. 479 00:15:39,340 --> 00:15:41,049 And this really makes me wonder, why 480 00:15:41,050 --> 00:15:42,939 can't you just safely run third party 481 00:15:42,940 --> 00:15:44,319 executables directly? 482 00:15:44,320 --> 00:15:46,269 Why do I first need to set up a VM? 483 00:15:46,270 --> 00:15:48,459 You spend an hour installing VMware, 484 00:15:48,460 --> 00:15:50,589 etc., or virtual box, 485 00:15:50,590 --> 00:15:52,809 putting a distro in there and just 486 00:15:52,810 --> 00:15:54,639 to run the single executable, why isn't 487 00:15:54,640 --> 00:15:56,439 there like a sane, simple environment 488 00:15:56,440 --> 00:15:57,939 that I can use to run the sandbox 489 00:15:57,940 --> 00:15:58,940 executables? 490 00:16:02,550 --> 00:16:04,439 So as I mentioned before, that the second 491 00:16:04,440 --> 00:16:06,659 problem I have with you is regarding 492 00:16:06,660 --> 00:16:08,909 reusability and testability and. 493 00:16:10,490 --> 00:16:12,409 When I first wrote these slides, I had a 494 00:16:12,410 --> 00:16:14,119 really hard time coming up with the right 495 00:16:14,120 --> 00:16:16,219 way to sort of explain what 496 00:16:16,220 --> 00:16:17,809 I think is wrong with reusability and 497 00:16:17,810 --> 00:16:19,939 testability. So eventually I came 498 00:16:19,940 --> 00:16:22,489 up with a way of sort of 499 00:16:22,490 --> 00:16:24,679 coming up with an analogy, and instead 500 00:16:24,680 --> 00:16:26,899 of looking at Eunuch's, let's sort 501 00:16:26,900 --> 00:16:28,339 of take a step back and take a look at 502 00:16:28,340 --> 00:16:30,769 sort of software development in general, 503 00:16:30,770 --> 00:16:32,719 namely, you know, programing. 504 00:16:32,720 --> 00:16:34,369 And let's just take a look at Java 505 00:16:34,370 --> 00:16:36,379 programing. For example, if you would 506 00:16:36,380 --> 00:16:38,479 write your simple Web server in Java, you 507 00:16:38,480 --> 00:16:39,889 would probably write something like this. 508 00:16:39,890 --> 00:16:41,719 You'd start out with a class class Web 509 00:16:41,720 --> 00:16:44,029 server and it has a constructor. 510 00:16:44,030 --> 00:16:45,379 And this constructor sets a couple of 511 00:16:45,380 --> 00:16:47,059 internal members at initializes the 512 00:16:47,060 --> 00:16:48,799 class. And what does it do? 513 00:16:48,800 --> 00:16:50,879 It creates a TCP socket that runs on Port 514 00:16:50,880 --> 00:16:53,119 80 and it has some 515 00:16:53,120 --> 00:16:54,889 kind of root directory by your files are 516 00:16:54,890 --> 00:16:55,890 stored. 517 00:16:57,470 --> 00:16:59,269 This works, but most people would agree 518 00:16:59,270 --> 00:17:00,799 with me that this is not the sort of the 519 00:17:00,800 --> 00:17:02,389 tidiest code you would write if you would 520 00:17:02,390 --> 00:17:04,489 just write this for your employer and 521 00:17:04,490 --> 00:17:05,659 send it out for code review. 522 00:17:05,660 --> 00:17:07,578 And hopefully one of your colleagues will 523 00:17:07,579 --> 00:17:09,259 just, you know, come over to your desk 524 00:17:09,260 --> 00:17:11,449 and slap you in the face 525 00:17:11,450 --> 00:17:13,639 because because, 526 00:17:13,640 --> 00:17:15,108 you know, this Web server is completely 527 00:17:15,109 --> 00:17:16,639 not flexible. Reuseable, of course. 528 00:17:16,640 --> 00:17:18,649 I mean, it always this on board and it 529 00:17:18,650 --> 00:17:20,358 always uses the same directory. 530 00:17:20,359 --> 00:17:21,619 So what you do is you sort of 531 00:17:22,640 --> 00:17:24,739 extend the constructor, make 532 00:17:24,740 --> 00:17:26,328 it possible to pass in a couple of extra 533 00:17:26,329 --> 00:17:27,739 parameters, name the airport number and 534 00:17:27,740 --> 00:17:28,740 the root directory. 535 00:17:29,600 --> 00:17:30,949 This is already a step in the right 536 00:17:30,950 --> 00:17:32,869 direction. But then you're sort of 537 00:17:32,870 --> 00:17:35,339 veteran Java programmer. 538 00:17:35,340 --> 00:17:37,459 My colleague comes to you and says, 539 00:17:37,460 --> 00:17:38,899 no, no, this is still wrong. 540 00:17:38,900 --> 00:17:41,029 You know, you need to use interfaces or 541 00:17:41,030 --> 00:17:43,099 come up with nice abstractions 542 00:17:43,100 --> 00:17:44,659 and layers in your application to make it 543 00:17:44,660 --> 00:17:45,959 more easy to test. 544 00:17:45,960 --> 00:17:48,019 So most Java programmers would 545 00:17:48,020 --> 00:17:49,699 actually write something like this, 546 00:17:49,700 --> 00:17:51,799 namely, instead of just creating 547 00:17:51,800 --> 00:17:54,229 like the TCP socket inside of the class, 548 00:17:54,230 --> 00:17:55,699 you just make it possible that a sort of 549 00:17:55,700 --> 00:17:58,069 an abstract socket type can be passed in 550 00:17:58,070 --> 00:17:59,449 and the same thing holds for the falsus 551 00:17:59,450 --> 00:18:00,889 nexus. Instead of putting all of that 552 00:18:00,890 --> 00:18:02,959 filesystem X's logic inside of the 553 00:18:02,960 --> 00:18:05,149 Web server class, you could also just 554 00:18:05,150 --> 00:18:07,399 create an interface that, for example, 555 00:18:07,400 --> 00:18:09,729 has a function, get 556 00:18:09,730 --> 00:18:11,989 full content and you pass in like a file 557 00:18:11,990 --> 00:18:13,279 name or something like that. And it just 558 00:18:13,280 --> 00:18:15,379 returns also file contents 559 00:18:15,380 --> 00:18:16,399 of some kind of buffer. 560 00:18:16,400 --> 00:18:18,019 And what you can do now with this class 561 00:18:18,020 --> 00:18:19,020 is you can 562 00:18:20,300 --> 00:18:22,759 test the entire class without 563 00:18:22,760 --> 00:18:24,859 actually constructing a single 564 00:18:24,860 --> 00:18:26,449 networking socket through the operating 565 00:18:26,450 --> 00:18:28,219 system or accessing a single file on 566 00:18:28,220 --> 00:18:29,929 disk. This is something that you can test 567 00:18:29,930 --> 00:18:30,930 really easily. 568 00:18:31,790 --> 00:18:34,479 Now, if we take a UNIX applications, 569 00:18:34,480 --> 00:18:36,349 you know, I just showed you like three 570 00:18:36,350 --> 00:18:37,819 different ways of solving it. 571 00:18:37,820 --> 00:18:39,379 If you now look at Unix applications, you 572 00:18:39,380 --> 00:18:41,479 see that they always sort of 573 00:18:41,480 --> 00:18:43,489 stick to one of the first two examples 574 00:18:43,490 --> 00:18:45,139 that I showed. It's either the case that 575 00:18:45,140 --> 00:18:46,729 the behavior of the applications is hard 576 00:18:46,730 --> 00:18:48,799 coded or they you 577 00:18:48,800 --> 00:18:50,539 know, they they write stuff to hard code 578 00:18:50,540 --> 00:18:53,239 locations on this score, assume certain, 579 00:18:53,240 --> 00:18:55,339 you know, locations where 580 00:18:55,340 --> 00:18:57,499 they can access services, for example, 581 00:18:57,500 --> 00:18:59,629 UNIX utilities, they all sort of somehow 582 00:18:59,630 --> 00:19:02,329 know that they can open fire run 583 00:19:02,330 --> 00:19:03,979 name, server caching, demon, dot, 584 00:19:03,980 --> 00:19:06,169 whatever to to exist like a name server 585 00:19:06,170 --> 00:19:07,999 caching. There's no actually way to sort 586 00:19:08,000 --> 00:19:10,369 of override this behavior 587 00:19:10,370 --> 00:19:12,469 really easily. So if they don't hard code 588 00:19:12,470 --> 00:19:14,089 that kind of behavior, it's typically 589 00:19:14,090 --> 00:19:15,949 stored in configuration files that are 590 00:19:15,950 --> 00:19:18,319 stored at a hardcoded locations as well. 591 00:19:18,320 --> 00:19:20,479 And what you see is that application are 592 00:19:20,480 --> 00:19:22,189 is required to resources on behalf of you 593 00:19:22,190 --> 00:19:23,269 instead of having them. 594 00:19:23,270 --> 00:19:24,619 PASTAN So 595 00:19:25,670 --> 00:19:27,619 your Web server configuration, you don't 596 00:19:27,620 --> 00:19:29,329 start a Web server and provide it to 597 00:19:29,330 --> 00:19:31,849 network sockets that it needs to use. 598 00:19:31,850 --> 00:19:33,559 Instead, you write in the configuration 599 00:19:33,560 --> 00:19:36,059 files on which IP address important, 600 00:19:36,060 --> 00:19:37,879 which you listen. And this is really bad, 601 00:19:37,880 --> 00:19:39,289 in my opinion, because it doesn't allow 602 00:19:39,290 --> 00:19:41,639 you to sort of customize 603 00:19:41,640 --> 00:19:43,129 the behavior of the application. 604 00:19:43,130 --> 00:19:45,139 Say you want to use a TCP socket that has 605 00:19:45,140 --> 00:19:47,479 custom TCAP Tynemouth parameters 606 00:19:47,480 --> 00:19:48,710 or retransmission logic. 607 00:19:49,790 --> 00:19:51,169 If you want to add support for this, you 608 00:19:51,170 --> 00:19:52,189 actually need to add it to the Web 609 00:19:52,190 --> 00:19:53,569 server, because when it passes the 610 00:19:53,570 --> 00:19:55,429 configuration file, there needs to be an 611 00:19:55,430 --> 00:19:57,049 extra configuration attribute in there 612 00:19:57,050 --> 00:19:59,569 that allows you to specify 613 00:19:59,570 --> 00:20:01,759 the parameters or any options and 614 00:20:01,760 --> 00:20:03,889 those that need to be the use 615 00:20:03,890 --> 00:20:05,239 to create the TCP socket. 616 00:20:05,240 --> 00:20:07,369 So the Web server just builds 617 00:20:07,370 --> 00:20:09,349 up this huge baggage of all these 618 00:20:09,350 --> 00:20:10,849 configuration options that could have 619 00:20:10,850 --> 00:20:13,039 been sort 620 00:20:13,040 --> 00:20:15,139 of placed outside of the Web server. 621 00:20:15,140 --> 00:20:16,549 There's no reason why they needed to be 622 00:20:16,550 --> 00:20:18,859 in there. So Unix 623 00:20:18,860 --> 00:20:20,239 doesn't use dependency injection. 624 00:20:20,240 --> 00:20:21,499 And I think that this is a double 625 00:20:21,500 --> 00:20:23,269 standard. We're really hammering towards 626 00:20:23,270 --> 00:20:25,219 having testable and reusable software, 627 00:20:25,220 --> 00:20:26,659 but apparently we don't care about this 628 00:20:26,660 --> 00:20:28,279 at the application level. 629 00:20:28,280 --> 00:20:30,149 So here's an example of a reusable, 630 00:20:30,150 --> 00:20:31,699 untestable web server. 631 00:20:31,700 --> 00:20:33,440 I won't spend too much time on this, but 632 00:20:34,520 --> 00:20:36,409 what happens is instead of just creating 633 00:20:36,410 --> 00:20:38,209 the DSP sockets yourself, you could just 634 00:20:38,210 --> 00:20:40,279 assume that standard in it is 635 00:20:40,280 --> 00:20:42,409 a TCP socket, for example, and then 636 00:20:42,410 --> 00:20:43,849 you can just start up this Web server in 637 00:20:43,850 --> 00:20:45,799 any way. So, for example, it doesn't 638 00:20:45,800 --> 00:20:47,479 matter whether you use an IP before an 639 00:20:47,480 --> 00:20:49,339 IPv6 socket, it still works. 640 00:20:49,340 --> 00:20:51,589 It can use TGP, cetp, any 641 00:20:51,590 --> 00:20:53,119 kind of stream protocol out there. 642 00:20:53,120 --> 00:20:54,559 It can listen on any other support. 643 00:20:54,560 --> 00:20:56,629 No, the funny thing is you can even 644 00:20:56,630 --> 00:20:58,939 create a socket once and spawn 645 00:20:58,940 --> 00:21:00,769 a whole bunch of Web servers all using 646 00:21:00,770 --> 00:21:01,659 the same follow script. 647 00:21:01,660 --> 00:21:03,499 And then you've implemented concurrency 648 00:21:03,500 --> 00:21:05,089 without any additional effort. 649 00:21:05,090 --> 00:21:06,679 And this web service, of course, testable 650 00:21:06,680 --> 00:21:08,719 because you can just use a unique socket 651 00:21:08,720 --> 00:21:11,029 to inject requests and capture 652 00:21:11,030 --> 00:21:11,989 the responses again. 653 00:21:11,990 --> 00:21:14,089 So this is a, in my opinion, sort of 654 00:21:14,090 --> 00:21:15,469 a better model of what we see in Unix 655 00:21:15,470 --> 00:21:16,639 right now. 656 00:21:16,640 --> 00:21:18,769 So now I've, you know, spent a fair 657 00:21:18,770 --> 00:21:20,869 time introducing or explaining what 658 00:21:20,870 --> 00:21:23,149 I think is wrong with Cloud, with Unix 659 00:21:23,150 --> 00:21:24,199 Cloud API. 660 00:21:24,200 --> 00:21:26,239 Now, I'm going to explain what Cloud API 661 00:21:26,240 --> 00:21:28,309 is. And, you know, as you 662 00:21:28,310 --> 00:21:29,329 might have guessed, it's something that 663 00:21:29,330 --> 00:21:31,009 sort of attempts to solve this. 664 00:21:31,010 --> 00:21:33,139 So Cloud API 665 00:21:33,140 --> 00:21:35,419 is a new Unix like runtime 666 00:21:35,420 --> 00:21:37,669 environment that 667 00:21:37,670 --> 00:21:40,499 is think of it as. 668 00:21:40,500 --> 00:21:42,719 POSIX, the unique standard, plus 669 00:21:42,720 --> 00:21:44,039 all of the stuff that's provided by 670 00:21:44,040 --> 00:21:46,109 capsicum, minus all of the 671 00:21:46,110 --> 00:21:48,209 stuff that conflicts with capsicum. 672 00:21:48,210 --> 00:21:50,309 So this makes it 673 00:21:50,310 --> 00:21:51,869 a lot easier to write software that works 674 00:21:51,870 --> 00:21:53,219 well with capsicum. 675 00:21:53,220 --> 00:21:55,289 So if you would now write opened, if 676 00:21:55,290 --> 00:21:57,569 you read them, instead of just like 677 00:21:57,570 --> 00:21:59,309 making the program start up and fill at 678 00:21:59,310 --> 00:22:02,099 runtime, it now just feels to compile. 679 00:22:02,100 --> 00:22:04,229 And it's of course annoying if 680 00:22:04,230 --> 00:22:05,969 gold doesn't compile, but it's a lot 681 00:22:05,970 --> 00:22:08,519 easier to fix, you know, compilation 682 00:22:08,520 --> 00:22:10,589 bugs than it is to sort of track down 683 00:22:10,590 --> 00:22:12,689 these issues caused by the security 684 00:22:12,690 --> 00:22:14,789 framework. Because what I 685 00:22:14,790 --> 00:22:16,349 explained before, if the crypto library 686 00:22:16,350 --> 00:22:18,449 that I try to open do you random and then 687 00:22:18,450 --> 00:22:20,279 fill back to weak entropy, that's 688 00:22:20,280 --> 00:22:22,499 something that you really don't notice. 689 00:22:22,500 --> 00:22:23,879 The only way you can discover it is if 690 00:22:23,880 --> 00:22:25,649 you sort of trace the application and 691 00:22:25,650 --> 00:22:27,119 sort of take a look at the system called 692 00:22:27,120 --> 00:22:28,559 behavior and see what it does. 693 00:22:28,560 --> 00:22:30,929 That's how I, you know, 694 00:22:30,930 --> 00:22:32,309 discovered this issue. 695 00:22:32,310 --> 00:22:34,439 But if you remove all of those interfaces 696 00:22:34,440 --> 00:22:36,329 and it becomes really obvious where sort 697 00:22:36,330 --> 00:22:38,429 of the the problem points in your 698 00:22:38,430 --> 00:22:40,439 application, it makes it a lot easier to 699 00:22:40,440 --> 00:22:42,149 make software run in such a sandbox 700 00:22:42,150 --> 00:22:43,150 environment. 701 00:22:43,890 --> 00:22:45,989 So what's also nice about such an 702 00:22:45,990 --> 00:22:48,179 environment is that applications can 703 00:22:48,180 --> 00:22:49,949 no longer just create arbitrary TCP 704 00:22:49,950 --> 00:22:52,289 sockets or something like that or open 705 00:22:52,290 --> 00:22:54,209 arbitrary files on disk. 706 00:22:54,210 --> 00:22:56,429 There are no more global name spaces, 707 00:22:56,430 --> 00:22:58,829 as they're called, and 708 00:22:58,830 --> 00:23:00,449 this makes it really hard to hard code 709 00:23:00,450 --> 00:23:01,649 all of that kind of stuff in the 710 00:23:01,650 --> 00:23:03,569 application. So it's sort of you're 711 00:23:03,570 --> 00:23:05,489 really forcing the application to be 712 00:23:05,490 --> 00:23:08,369 written in a testable way, and 713 00:23:08,370 --> 00:23:10,199 I think that's good. 714 00:23:10,200 --> 00:23:12,029 It shouldn't be like this unconditionally 715 00:23:12,030 --> 00:23:13,799 because there's sort of of, of course, a 716 00:23:13,800 --> 00:23:15,929 very large amount of legacy software, 717 00:23:15,930 --> 00:23:17,549 existing UNIX software that needs to 718 00:23:17,550 --> 00:23:19,709 work. But it's not a bad 719 00:23:19,710 --> 00:23:21,359 idea to also, Nekesa, that sort of a 720 00:23:21,360 --> 00:23:23,759 clean slate Unix environment where 721 00:23:23,760 --> 00:23:25,649 testability and security is sort of a 722 00:23:25,650 --> 00:23:26,579 prime focus. 723 00:23:26,580 --> 00:23:28,589 And that's also like the point that I 724 00:23:28,590 --> 00:23:30,179 want to make at the bottom of the slide. 725 00:23:30,180 --> 00:23:31,319 Often when I give this talk at 726 00:23:31,320 --> 00:23:32,519 conferences, there are people that sort 727 00:23:32,520 --> 00:23:33,779 of walk up to the microphone and say, 728 00:23:33,780 --> 00:23:36,059 like, this is nice, but it wouldn't work 729 00:23:36,060 --> 00:23:38,249 for traditional Unix 730 00:23:38,250 --> 00:23:39,569 use case X. 731 00:23:39,570 --> 00:23:40,799 That's of course, really not what I'm 732 00:23:40,800 --> 00:23:43,619 focusing on. This is really a clean slate 733 00:23:43,620 --> 00:23:44,620 approach. 734 00:23:45,990 --> 00:23:48,119 So just to sort of rehash what 735 00:23:48,120 --> 00:23:50,159 a cloud API program can do by default, if 736 00:23:50,160 --> 00:23:51,569 you would just start up the simplest 737 00:23:51,570 --> 00:23:53,909 cloud API process possible, it can 738 00:23:53,910 --> 00:23:55,049 still allocate memory. 739 00:23:55,050 --> 00:23:57,329 It can create pipes, it can create 740 00:23:57,330 --> 00:23:58,799 socket pairs, it can create shared 741 00:23:58,800 --> 00:24:01,199 memory. In other words, it can do ipse 742 00:24:01,200 --> 00:24:02,200 with itself. 743 00:24:03,450 --> 00:24:05,519 It can also spawn Freds and it can also 744 00:24:05,520 --> 00:24:06,809 spawn subprocesses. 745 00:24:06,810 --> 00:24:09,269 So it can Falke 746 00:24:09,270 --> 00:24:11,489 or. Yeah, creating threads 747 00:24:11,490 --> 00:24:13,079 is not necessarily Forkan, but it can 748 00:24:13,080 --> 00:24:15,209 also form and it can also interact with 749 00:24:15,210 --> 00:24:17,309 some clocks. It can also even get random 750 00:24:17,310 --> 00:24:18,359 data from the kernel. 751 00:24:18,360 --> 00:24:20,429 Those are all things that are, you know, 752 00:24:20,430 --> 00:24:21,869 really not harmful in any way. 753 00:24:21,870 --> 00:24:23,549 If you're just sort of a small, tiny 754 00:24:23,550 --> 00:24:25,739 program running on some kind of computer, 755 00:24:25,740 --> 00:24:27,089 there's really no harm in getting the 756 00:24:27,090 --> 00:24:28,649 time of day or getting some random data 757 00:24:28,650 --> 00:24:29,879 from the kernel. 758 00:24:29,880 --> 00:24:31,679 But what the programs cannot do is open, 759 00:24:31,680 --> 00:24:33,869 arbitrary popson disk create network 760 00:24:33,870 --> 00:24:35,909 connections and it can also not just send 761 00:24:35,910 --> 00:24:38,579 signals to other processes on the system. 762 00:24:38,580 --> 00:24:40,769 That's already fenced off, so 763 00:24:40,770 --> 00:24:42,509 the simplest cloud by program, if you 764 00:24:42,510 --> 00:24:43,829 would, just random thoughts with 765 00:24:43,830 --> 00:24:45,959 whatever, it wouldn't be able to do any 766 00:24:45,960 --> 00:24:46,960 harm on your system. 767 00:24:52,700 --> 00:24:54,379 So then you want to sort of grant 768 00:24:54,380 --> 00:24:55,579 additional rights to this program to 769 00:24:55,580 --> 00:24:56,839 actually make it functional, and you do 770 00:24:56,840 --> 00:24:58,699 that in the form of file descriptors, so 771 00:24:58,700 --> 00:24:59,899 you make sure that your program is 772 00:24:59,900 --> 00:25:01,459 started up with the right set of follow 773 00:25:01,460 --> 00:25:02,719 scripts. And that's really critical. 774 00:25:02,720 --> 00:25:05,059 Just to make sure that you 775 00:25:05,060 --> 00:25:06,649 use the right set of follow scriptures to 776 00:25:06,650 --> 00:25:08,299 start up your process. 777 00:25:08,300 --> 00:25:10,429 And what you can do is you can just use 778 00:25:10,430 --> 00:25:11,899 follow descriptors to directories to 779 00:25:11,900 --> 00:25:13,369 access parts of the file system, which 780 00:25:13,370 --> 00:25:14,569 I've already mentioned. 781 00:25:14,570 --> 00:25:16,789 And this is really nice because in 782 00:25:16,790 --> 00:25:18,859 practice, this means that most 783 00:25:18,860 --> 00:25:20,179 of you people are probably familiar with 784 00:25:20,180 --> 00:25:21,799 the change root system, calling Unix, 785 00:25:21,800 --> 00:25:23,269 where you can lock up a process in the 786 00:25:23,270 --> 00:25:24,469 single directory. 787 00:25:24,470 --> 00:25:26,749 This is sort of change route on steroids. 788 00:25:26,750 --> 00:25:28,399 It allows you to create multiple change 789 00:25:28,400 --> 00:25:30,229 routes. Every file descriptor on its own 790 00:25:30,230 --> 00:25:32,149 is its own separate change route that you 791 00:25:32,150 --> 00:25:33,199 can access files underneath. 792 00:25:33,200 --> 00:25:34,200 So it's really powerful 793 00:25:35,510 --> 00:25:37,549 sockets to make a program network 794 00:25:37,550 --> 00:25:38,939 accessible. But it's also really nice to 795 00:25:38,940 --> 00:25:40,039 set unique supports. 796 00:25:40,040 --> 00:25:41,210 Follow scripter passing 797 00:25:42,620 --> 00:25:44,809 if you have a unique socket so it doesn't 798 00:25:44,810 --> 00:25:46,429 work for a TCP socket or anything, but 799 00:25:46,430 --> 00:25:48,139 just a local unique socket, you can 800 00:25:48,140 --> 00:25:49,819 actually be sure to follow script from 801 00:25:49,820 --> 00:25:51,949 one side of the socket and it sort 802 00:25:51,950 --> 00:25:53,689 of pops out on the other side. 803 00:25:53,690 --> 00:25:55,219 And this sort of allows for some really 804 00:25:55,220 --> 00:25:56,419 complex constructs where 805 00:25:57,950 --> 00:25:59,059 a program starts up. 806 00:25:59,060 --> 00:26:00,409 It doesn't have a lot of rights by 807 00:26:00,410 --> 00:26:02,659 default, but it really needs 808 00:26:02,660 --> 00:26:04,399 a sort of a specific right later on. 809 00:26:04,400 --> 00:26:06,529 It can sort of send an RPG over to some 810 00:26:06,530 --> 00:26:08,659 kind of process like, hey, 811 00:26:08,660 --> 00:26:10,939 I need to deliver this email for user X. 812 00:26:10,940 --> 00:26:11,989 Could you please give me a file 813 00:26:11,990 --> 00:26:13,999 descriptor to that person's mailbox and 814 00:26:14,000 --> 00:26:15,799 that other process then sort of sends a 815 00:26:15,800 --> 00:26:17,209 file descriptor back to you and you can 816 00:26:17,210 --> 00:26:18,449 sort of write an email into it. 817 00:26:18,450 --> 00:26:21,559 So this is a really powerful construct 818 00:26:21,560 --> 00:26:23,509 and also something that supports the 819 00:26:23,510 --> 00:26:24,889 so-called process descriptors. 820 00:26:24,890 --> 00:26:26,269 As I mentioned in the previous slide, you 821 00:26:26,270 --> 00:26:27,859 can't just send kill signals to arbitrary 822 00:26:27,860 --> 00:26:28,909 processes. 823 00:26:28,910 --> 00:26:30,829 So what capsicum did and what cloud API 824 00:26:30,830 --> 00:26:32,659 also supports this process descriptors, 825 00:26:32,660 --> 00:26:34,639 namely, there's a special for call. 826 00:26:34,640 --> 00:26:36,409 And if you invoke that call, you actually 827 00:26:36,410 --> 00:26:38,479 get a file descriptor to the 828 00:26:38,480 --> 00:26:39,529 child process. 829 00:26:39,530 --> 00:26:40,969 If you call close and that follows a 830 00:26:40,970 --> 00:26:43,159 script, it automatically kills a child 831 00:26:43,160 --> 00:26:45,259 process. So there's also no way for you 832 00:26:45,260 --> 00:26:47,150 to sort of leave resources behind. 833 00:26:48,560 --> 00:26:50,239 It should be noted, important mentioned 834 00:26:50,240 --> 00:26:52,019 at some previous conference, someone made 835 00:26:52,020 --> 00:26:53,359 the smart remark. 836 00:26:53,360 --> 00:26:55,069 Yes, but what if you can pass process 837 00:26:55,070 --> 00:26:56,869 descriptors through unique sockets? 838 00:26:56,870 --> 00:26:59,899 Because you could, for example, allow 839 00:26:59,900 --> 00:27:01,759 a process of scripter to be passed 840 00:27:01,760 --> 00:27:03,589 through the child process itself and then 841 00:27:03,590 --> 00:27:05,209 the child process can remain alive 842 00:27:05,210 --> 00:27:06,259 indefinitely. 843 00:27:06,260 --> 00:27:08,389 So that's not possible. 844 00:27:08,390 --> 00:27:10,159 Process descriptors are not possible for 845 00:27:10,160 --> 00:27:12,109 unique sockets. That's that's a 846 00:27:12,110 --> 00:27:14,059 restriction that's placed on this model. 847 00:27:14,060 --> 00:27:15,469 File descriptors also have permission, 848 00:27:15,470 --> 00:27:16,879 Titmouse, and they allow you to sort of 849 00:27:16,880 --> 00:27:18,559 really gradually turn off certain 850 00:27:18,560 --> 00:27:20,779 privileges so you could create a piece 851 00:27:20,780 --> 00:27:21,919 of shit memory. 852 00:27:21,920 --> 00:27:23,599 Scheft memory file descriptor, which is 853 00:27:23,600 --> 00:27:25,519 rewritable for you, but then you 854 00:27:25,520 --> 00:27:27,019 duplicate to follow Scripter about on 855 00:27:27,020 --> 00:27:28,369 that second instance, you remove the 856 00:27:28,370 --> 00:27:30,319 right bits and that follows descriptor. 857 00:27:30,320 --> 00:27:32,029 You send it over to another process and 858 00:27:32,030 --> 00:27:33,769 then that other process can only read 859 00:27:33,770 --> 00:27:35,239 from the shared memory space and not 860 00:27:35,240 --> 00:27:36,319 write into it. 861 00:27:36,320 --> 00:27:38,209 So this is also an important concept. 862 00:27:38,210 --> 00:27:39,949 Without this file descriptor permission 863 00:27:39,950 --> 00:27:41,419 titmouse, then the system would be a lot 864 00:27:41,420 --> 00:27:42,559 weaker than it is right now. 865 00:27:44,210 --> 00:27:45,949 So the secure web service, how would you 866 00:27:45,950 --> 00:27:47,089 live in Cloud Abai? 867 00:27:47,090 --> 00:27:49,279 Well, it's pretty straightforward 868 00:27:49,280 --> 00:27:50,809 for every sort of bullet point that I had 869 00:27:50,810 --> 00:27:52,159 and one of the previous slides, you just 870 00:27:52,160 --> 00:27:53,869 replace it by a file descriptor 871 00:27:53,870 --> 00:27:56,209 essentially. So for example, 872 00:27:56,210 --> 00:27:57,389 you can use an affinity. 873 00:27:57,390 --> 00:27:59,659 Or if I had six TCP 874 00:27:59,660 --> 00:28:01,159 socket for all the incoming HTTP 875 00:28:01,160 --> 00:28:03,289 requests, you can use read-only 876 00:28:03,290 --> 00:28:05,299 file descriptor for the directory 877 00:28:05,300 --> 00:28:07,559 containing all of the Webroot files. 878 00:28:07,560 --> 00:28:09,379 So it only has to read capability's but 879 00:28:09,380 --> 00:28:11,689 not write and not truncate, etc.. 880 00:28:11,690 --> 00:28:13,369 So that means that an attacker can never 881 00:28:13,370 --> 00:28:15,439 actually modify, modify the files that 882 00:28:15,440 --> 00:28:16,579 are stored on your web server root 883 00:28:16,580 --> 00:28:17,479 directory. 884 00:28:17,480 --> 00:28:19,549 And you can also give this web 885 00:28:19,550 --> 00:28:21,319 server and append only file descriptor 886 00:28:21,320 --> 00:28:23,209 that only has the right capability set to 887 00:28:23,210 --> 00:28:25,399 it, meaning that the only thing 888 00:28:25,400 --> 00:28:26,929 that an attacker can do in the worst case 889 00:28:26,930 --> 00:28:28,649 is append garbage to the log file. 890 00:28:28,650 --> 00:28:30,379 It cannot truncate lock files, can 891 00:28:30,380 --> 00:28:31,969 overwrite its previous entries. 892 00:28:31,970 --> 00:28:34,069 It can only add more stuff to it, which 893 00:28:34,070 --> 00:28:35,070 is nice. 894 00:28:35,780 --> 00:28:37,939 So when I started hacking on this, I 895 00:28:37,940 --> 00:28:40,129 observed that Unix becomes really tiny, 896 00:28:40,130 --> 00:28:42,379 really small if you remove all of this 897 00:28:42,380 --> 00:28:44,389 legacy cruft from it to begin with, but 898 00:28:44,390 --> 00:28:45,979 also all of the interfaces that are 899 00:28:45,980 --> 00:28:48,079 incompatible with the security model. 900 00:28:48,080 --> 00:28:50,419 So Cloud API only has 58 system 901 00:28:50,420 --> 00:28:51,680 calls and 902 00:28:52,760 --> 00:28:55,229 which is pretty tiny, and 903 00:28:55,230 --> 00:28:56,689 especially if you compare to Linux, for 904 00:28:56,690 --> 00:28:58,489 example, because Linux has 300 and 905 00:28:58,490 --> 00:29:00,289 FreeBSD even as almost 400. 906 00:29:00,290 --> 00:29:02,389 I think so it's 907 00:29:02,390 --> 00:29:03,469 a lot simpler to implement. 908 00:29:03,470 --> 00:29:04,819 And what this means is that you can add 909 00:29:04,820 --> 00:29:06,529 support for Cloud API to existing 910 00:29:06,530 --> 00:29:07,909 operating systems. 911 00:29:07,910 --> 00:29:10,279 So I started adding support 912 00:29:10,280 --> 00:29:12,349 for Cloud API to free BSD and it only 913 00:29:12,350 --> 00:29:15,169 required me to write, I think, 6000 914 00:29:15,170 --> 00:29:16,609 lines of code. 915 00:29:16,610 --> 00:29:18,409 And that is sort of enough support to run 916 00:29:18,410 --> 00:29:20,419 all of the sort of to run all of those 917 00:29:20,420 --> 00:29:22,069 cloud API system calls. 918 00:29:22,070 --> 00:29:24,139 And now I'm also working on adding 919 00:29:24,140 --> 00:29:25,849 support to Linux and that be easy to not 920 00:29:25,850 --> 00:29:27,589 be used for this really robust because 921 00:29:27,590 --> 00:29:29,359 it's sort of similar in structure to 922 00:29:29,360 --> 00:29:30,319 FreeBSD. 923 00:29:30,320 --> 00:29:31,929 Linux requires some more work because 924 00:29:31,930 --> 00:29:34,189 sort of being able to run 925 00:29:34,190 --> 00:29:35,959 multiple binary interfaces is something 926 00:29:35,960 --> 00:29:38,479 that's not sort of a core concept 927 00:29:38,480 --> 00:29:39,649 of the Linux kernel doesn't really 928 00:29:39,650 --> 00:29:41,809 support that. So I had to add some moves 929 00:29:41,810 --> 00:29:44,089 to that. But it means that 930 00:29:44,090 --> 00:29:45,859 you only patch up the operating systems 931 00:29:45,860 --> 00:29:47,899 by adding a couple of thousand lines of 932 00:29:47,900 --> 00:29:49,160 code and then you can 933 00:29:50,960 --> 00:29:51,959 run programs to. 934 00:29:51,960 --> 00:29:53,409 Recombining them, which is pretty sweet 935 00:29:53,410 --> 00:29:55,149 in my opinion, especially for sort of 936 00:29:55,150 --> 00:29:57,549 cloud computing cases where 937 00:29:57,550 --> 00:29:59,139 you're just a hosting provider and want 938 00:29:59,140 --> 00:30:01,029 to run binaries that are provided by 939 00:30:01,030 --> 00:30:02,529 other people. This is sort of a real 940 00:30:02,530 --> 00:30:04,449 killer feature, in my opinion. 941 00:30:04,450 --> 00:30:06,549 So now I'm going to explain 942 00:30:06,550 --> 00:30:07,929 a couple more things. For example, how 943 00:30:07,930 --> 00:30:09,939 can you develop software for cloud API? 944 00:30:09,940 --> 00:30:12,339 So, first of all, compiling in general 945 00:30:12,340 --> 00:30:14,259 is pretty hard. 946 00:30:14,260 --> 00:30:15,999 This means that it's typically not that 947 00:30:16,000 --> 00:30:17,859 easy to build software for Cloud API out 948 00:30:17,860 --> 00:30:18,860 of the box. 949 00:30:19,570 --> 00:30:21,099 And of course, I've been working on 950 00:30:21,100 --> 00:30:22,269 making this a lot smoother and I'll 951 00:30:22,270 --> 00:30:24,219 explain how I've been doing that in the 952 00:30:24,220 --> 00:30:25,509 next couple of days. 953 00:30:25,510 --> 00:30:27,669 But the problem is that the 954 00:30:27,670 --> 00:30:29,949 toolchain to the entire toolchain 955 00:30:29,950 --> 00:30:31,539 for building cloud API software depends 956 00:30:31,540 --> 00:30:33,709 on a lot of sort of separate components. 957 00:30:33,710 --> 00:30:36,099 So there's a compiler, assembler Linko, 958 00:30:36,100 --> 00:30:38,139 that you need a standard library, C++ 959 00:30:38,140 --> 00:30:39,879 Library Exception Handling Library, MAFF 960 00:30:39,880 --> 00:30:41,259 Library. 961 00:30:41,260 --> 00:30:42,609 It's just a whole list. 962 00:30:42,610 --> 00:30:44,319 And then you only have sort of the bare 963 00:30:44,320 --> 00:30:46,929 minimum of building cloud API software. 964 00:30:46,930 --> 00:30:48,579 And setting that up is pretty time 965 00:30:48,580 --> 00:30:49,519 consuming, of course. 966 00:30:49,520 --> 00:30:51,459 And in addition to that, you also need to 967 00:30:51,460 --> 00:30:52,959 patch up any piece of software that you 968 00:30:52,960 --> 00:30:55,059 want to use. So removal 969 00:30:55,060 --> 00:30:56,889 of all of this capability, unaware APIs 970 00:30:56,890 --> 00:30:58,209 really breaks to build in a couple of 971 00:30:58,210 --> 00:31:00,249 places. And at the same time, I'm also 972 00:31:00,250 --> 00:31:01,839 trying to cut down on sort of some 973 00:31:01,840 --> 00:31:03,609 non-unique extensions that 974 00:31:05,230 --> 00:31:07,389 are either obsolete or don't make 975 00:31:07,390 --> 00:31:09,099 a lot of sense where the C standard has 976 00:31:09,100 --> 00:31:11,559 already caught up and provide interface 977 00:31:11,560 --> 00:31:13,509 that are a lot nicer and also really 978 00:31:13,510 --> 00:31:15,159 annoying. Some build infrastructure like 979 00:31:15,160 --> 00:31:17,289 all the doesn't even support cloud API to 980 00:31:17,290 --> 00:31:18,699 begin with. It does now. 981 00:31:18,700 --> 00:31:20,409 But that means if you have any source 982 00:31:20,410 --> 00:31:23,259 darbo from before March 2015, 983 00:31:23,260 --> 00:31:24,999 if you Randallstown configure on it and 984 00:31:25,000 --> 00:31:26,439 want to cross compile something for cloud 985 00:31:26,440 --> 00:31:28,389 API, it will simply say, I don't know 986 00:31:28,390 --> 00:31:29,349 this operating system. 987 00:31:29,350 --> 00:31:31,509 So that's a bit 988 00:31:31,510 --> 00:31:33,219 annoying. So to to mitigate this, I've 989 00:31:33,220 --> 00:31:34,359 been working on something called the Cloud 990 00:31:34,360 --> 00:31:35,919 API Port's collection and what it is. 991 00:31:35,920 --> 00:31:37,809 It's just a collection of build scripts 992 00:31:37,810 --> 00:31:38,890 that allow you to build 993 00:31:40,000 --> 00:31:41,979 a whole bunch of open source libraries. 994 00:31:41,980 --> 00:31:44,259 And libraries include Boost, which 995 00:31:44,260 --> 00:31:46,509 is really nice of you to C++ programing. 996 00:31:46,510 --> 00:31:49,689 Kerl if you want to do some HTP access, 997 00:31:49,690 --> 00:31:51,939 Jilib, which is part of a lot of them, 998 00:31:51,940 --> 00:31:53,379 sort of garnham desktop centric 999 00:31:53,380 --> 00:31:54,519 applications. 1000 00:31:54,520 --> 00:31:56,289 There's even crypto libraries as well. 1001 00:31:56,290 --> 00:31:58,299 And also I've started working on some 1002 00:31:58,300 --> 00:31:59,889 scripting language support. 1003 00:31:59,890 --> 00:32:02,259 Lubar in this case I'm working on Python 1004 00:32:02,260 --> 00:32:03,939 in the meantime, which is going to be a 1005 00:32:03,940 --> 00:32:05,709 lot more exciting, of course. 1006 00:32:05,710 --> 00:32:07,509 But what's nice about API ports is that 1007 00:32:07,510 --> 00:32:09,609 it builds those packages once 1008 00:32:09,610 --> 00:32:11,919 I build them on my Linux workstation 1009 00:32:11,920 --> 00:32:14,229 or my FreeBSD server, and then it turns 1010 00:32:14,230 --> 00:32:16,359 them into a bunch of native packages for 1011 00:32:16,360 --> 00:32:17,829 different operating systems. 1012 00:32:17,830 --> 00:32:19,569 So it automatically generates freebees 1013 00:32:19,570 --> 00:32:22,029 the packages, Debian packages, etc.. 1014 00:32:22,030 --> 00:32:24,159 So what you as an end user only need to 1015 00:32:24,160 --> 00:32:26,349 do is you can just go to like my 1016 00:32:26,350 --> 00:32:28,419 website if you the link at the very end 1017 00:32:28,420 --> 00:32:30,279 of the stock and it has some instructions 1018 00:32:30,280 --> 00:32:31,779 on how you can add a couple of lines to 1019 00:32:31,780 --> 00:32:33,969 your Etsy app sources of list or 1020 00:32:33,970 --> 00:32:36,069 your freebees the package configuration, 1021 00:32:36,070 --> 00:32:37,989 and then you can just use objets or pkg 1022 00:32:37,990 --> 00:32:39,129 to fetch those packages. 1023 00:32:39,130 --> 00:32:40,789 And they're identical across the 1024 00:32:40,790 --> 00:32:42,429 operating system. They're like byte for 1025 00:32:42,430 --> 00:32:43,430 byte identical. 1026 00:32:44,820 --> 00:32:46,619 And this means that you have a really 1027 00:32:46,620 --> 00:32:48,719 consistent development environment that 1028 00:32:48,720 --> 00:32:50,609 you can use to develop software so it 1029 00:32:50,610 --> 00:32:52,169 doesn't matter if you're compiling an 1030 00:32:52,170 --> 00:32:54,269 application or Linux or BSD in 1031 00:32:54,270 --> 00:32:57,539 theory, unfortunately, not in practice 1032 00:32:57,540 --> 00:32:59,399 that the checksums of the binaries should 1033 00:32:59,400 --> 00:33:00,959 be identical, which is really nice and 1034 00:33:00,960 --> 00:33:03,029 heterogeneous development environment. 1035 00:33:03,030 --> 00:33:05,159 Um, I want to explain why 1036 00:33:05,160 --> 00:33:06,929 the binaries aren't exactly identical, 1037 00:33:06,930 --> 00:33:08,909 but it's if someone wants to grab a beer 1038 00:33:08,910 --> 00:33:10,949 with me, I can explain. It is horrible. 1039 00:33:10,950 --> 00:33:13,139 So to clarify, these 1040 00:33:13,140 --> 00:33:15,749 packages don't contain any native 1041 00:33:15,750 --> 00:33:16,649 build tools. 1042 00:33:16,650 --> 00:33:17,999 These packages are all built on my 1043 00:33:18,000 --> 00:33:19,379 Phoebes, your Linux system, and they 1044 00:33:19,380 --> 00:33:21,479 don't have any cross compiler that you 1045 00:33:21,480 --> 00:33:23,009 can run on OpenBSD. 1046 00:33:23,010 --> 00:33:25,109 These are just across compound libraries. 1047 00:33:25,110 --> 00:33:27,389 And the goal is that sort of the 1048 00:33:27,390 --> 00:33:28,709 actual native tooling needs to be 1049 00:33:28,710 --> 00:33:31,079 provided by your own operating system 1050 00:33:31,080 --> 00:33:32,189 vendor yourself. 1051 00:33:32,190 --> 00:33:33,689 So if you're a package maintainer for 1052 00:33:33,690 --> 00:33:35,639 some kind of distro operating system, you 1053 00:33:35,640 --> 00:33:37,589 know, I'd love to talk to you because I 1054 00:33:37,590 --> 00:33:39,629 can only always use cloud API packages 1055 00:33:39,630 --> 00:33:40,880 for more operating systems. 1056 00:33:42,000 --> 00:33:44,099 So here's just like a real 1057 00:33:44,100 --> 00:33:45,839 quick explanation of how you install such 1058 00:33:45,840 --> 00:33:47,849 a cross compiler toolchain on Freebo is 1059 00:33:47,850 --> 00:33:50,089 the icepick FreeBSD 1060 00:33:50,090 --> 00:33:52,169 year because the steps are a bit 1061 00:33:52,170 --> 00:33:53,429 easier than that on Linux. 1062 00:33:53,430 --> 00:33:54,689 And I wanted to make it look pretty, of 1063 00:33:54,690 --> 00:33:56,759 course, and 1064 00:33:56,760 --> 00:33:58,799 so on freebees that you first just run 1065 00:33:58,800 --> 00:34:00,479 this command package, install cloud API 1066 00:34:00,480 --> 00:34:01,979 toolchain, which gives you a copy of the 1067 00:34:01,980 --> 00:34:03,569 latest version of Klang and the latest 1068 00:34:03,570 --> 00:34:05,669 version of Utils targeting 1069 00:34:05,670 --> 00:34:07,229 Cloud API. And these packages are 1070 00:34:07,230 --> 00:34:08,609 provided by freebees Needham's. 1071 00:34:10,520 --> 00:34:11,779 Once you're done, you already have a 1072 00:34:11,780 --> 00:34:13,399 compiler, but it can't compile anything 1073 00:34:13,400 --> 00:34:14,988 because there's not a single cloud API 1074 00:34:14,989 --> 00:34:16,529 library installed in your system. 1075 00:34:16,530 --> 00:34:18,948 So what you do is you just add a 1076 00:34:18,949 --> 00:34:21,079 couple of snippets to slash EDC and 1077 00:34:21,080 --> 00:34:22,549 then you can run package update, followed 1078 00:34:22,550 --> 00:34:24,919 by, you know, this long package installed 1079 00:34:24,920 --> 00:34:26,988 command. And you know what 1080 00:34:26,989 --> 00:34:28,158 you see over here. 1081 00:34:28,159 --> 00:34:30,499 This is the name of the architecture X 1082 00:34:30,500 --> 00:34:32,599 86 64 Cloud API, and 1083 00:34:32,600 --> 00:34:33,888 this is the name of the package and in 1084 00:34:33,889 --> 00:34:35,269 the runtime. 1085 00:34:35,270 --> 00:34:36,709 So if you install this package, you get a 1086 00:34:36,710 --> 00:34:39,019 C library, a standard C++ library, 1087 00:34:39,020 --> 00:34:41,899 enough to do standard C++ hacking. 1088 00:34:41,900 --> 00:34:43,399 And then once that's done, you can 1089 00:34:43,400 --> 00:34:44,988 already just invoke the cross compiler 1090 00:34:44,989 --> 00:34:47,599 and compile any software you like, even 1091 00:34:47,600 --> 00:34:49,260 including Hello World Applications. 1092 00:34:50,900 --> 00:34:52,819 So now that I've explained how you can 1093 00:34:52,820 --> 00:34:54,349 sort of develop your Cloud API software, 1094 00:34:54,350 --> 00:34:56,658 we're going to look at starting them up. 1095 00:34:56,659 --> 00:34:58,819 And it's actually 1096 00:34:58,820 --> 00:35:00,199 sort of more interesting than you think. 1097 00:35:00,200 --> 00:35:02,719 There's more to it than meets the eye 1098 00:35:02,720 --> 00:35:04,369 if we're going to take a look at a very 1099 00:35:04,370 --> 00:35:05,779 simple Unix application. 1100 00:35:05,780 --> 00:35:07,879 So, for example, many 1101 00:35:07,880 --> 00:35:09,049 people have used this application. 1102 00:35:09,050 --> 00:35:10,459 I will need to explain what this tool 1103 00:35:10,460 --> 00:35:12,799 does it 1104 00:35:12,800 --> 00:35:14,059 anyway. 1105 00:35:14,060 --> 00:35:15,619 What we do is instead of just 1106 00:35:16,670 --> 00:35:18,769 calling, you know, open there 1107 00:35:18,770 --> 00:35:20,839 on Dottore, what else does by default, 1108 00:35:20,840 --> 00:35:22,549 it opens the current directory and 1109 00:35:22,550 --> 00:35:24,139 fetches the directory entries. 1110 00:35:25,390 --> 00:35:27,049 There's no way we can do this because the 1111 00:35:27,050 --> 00:35:28,909 application has no working directory 1112 00:35:28,910 --> 00:35:30,589 anymore. It's simply not there anymore in 1113 00:35:30,590 --> 00:35:32,239 cloud API. So we call F.T. 1114 00:35:32,240 --> 00:35:33,739 opened here, which allows us to open a 1115 00:35:33,740 --> 00:35:34,940 directory by file descriptor. 1116 00:35:36,540 --> 00:35:38,639 We then there on it in a loop 1117 00:35:38,640 --> 00:35:40,949 and then just print all of the entries 1118 00:35:40,950 --> 00:35:43,019 that are in there, you also see that 1119 00:35:43,020 --> 00:35:44,819 there is no standard out in this runtime 1120 00:35:44,820 --> 00:35:45,959 environment. 1121 00:35:45,960 --> 00:35:47,399 You know, it's really just we need to 1122 00:35:47,400 --> 00:35:49,379 assume that standard in our sorry 1123 00:35:49,380 --> 00:35:51,629 standard out happens to correspond with 1124 00:35:51,630 --> 00:35:53,129 a script or one. So that's what the FDA 1125 00:35:53,130 --> 00:35:54,689 open call for. 1126 00:35:54,690 --> 00:35:56,939 So how can we invoked 1127 00:35:56,940 --> 00:35:58,769 this application in a bit of a sort of a 1128 00:35:58,770 --> 00:35:59,939 less traditional way? 1129 00:35:59,940 --> 00:36:01,949 We first compile it, run it through cross 1130 00:36:01,950 --> 00:36:04,049 compiler, then we load up a kernel module 1131 00:36:04,050 --> 00:36:06,419 that's needed on FreeBSD to to run this 1132 00:36:06,420 --> 00:36:07,769 nice thing as this is already just 1133 00:36:07,770 --> 00:36:09,959 integrated into FreeBSD 11 by 1134 00:36:09,960 --> 00:36:11,219 default. So if you just download the 1135 00:36:11,220 --> 00:36:13,439 latest development snapshot of freebees 1136 00:36:13,440 --> 00:36:15,719 the run called Loudcloud Cloud API 1137 00:36:15,720 --> 00:36:17,879 64, it works out of the box. 1138 00:36:17,880 --> 00:36:19,889 No packages needed, no patches need. 1139 00:36:19,890 --> 00:36:22,019 It just works pretty awesome. 1140 00:36:22,020 --> 00:36:23,519 And then when you have the binary, you 1141 00:36:23,520 --> 00:36:24,899 can just run less. 1142 00:36:24,900 --> 00:36:26,699 But we need to provide it a file 1143 00:36:26,700 --> 00:36:28,839 descriptor to a directory of 1144 00:36:28,840 --> 00:36:30,749 a ophthalmoscope to zero. 1145 00:36:30,750 --> 00:36:33,239 We just run such a small one and 1146 00:36:33,240 --> 00:36:34,859 see which works. 1147 00:36:34,860 --> 00:36:35,969 It prints all of the entries in the 1148 00:36:35,970 --> 00:36:38,279 directory. So this is like a cloud 1149 00:36:38,280 --> 00:36:39,959 API. Hello. World application in a 1150 00:36:39,960 --> 00:36:40,960 certain way. 1151 00:36:41,760 --> 00:36:44,549 So even though this works, 1152 00:36:44,550 --> 00:36:46,289 this is not really a natural way of 1153 00:36:46,290 --> 00:36:47,489 starting processes. 1154 00:36:47,490 --> 00:36:49,619 It can really get out of hand. 1155 00:36:49,620 --> 00:36:51,329 Starting up a Web server with 20 1156 00:36:51,330 --> 00:36:52,709 different file descriptors, two different 1157 00:36:52,710 --> 00:36:54,089 DSP connections, etc.. 1158 00:36:54,090 --> 00:36:55,229 It really doesn't work. 1159 00:36:55,230 --> 00:36:58,049 It's the shell is not meant for that. 1160 00:36:58,050 --> 00:37:00,059 Even to make it worse, there's not a same 1161 00:37:00,060 --> 00:37:02,639 portable way in which you can create 1162 00:37:02,640 --> 00:37:04,799 network sockets through the shell, of 1163 00:37:04,800 --> 00:37:05,699 course. 1164 00:37:05,700 --> 00:37:07,739 And how do you know the ordering of the 1165 00:37:07,740 --> 00:37:09,029 follow scripture's? If you have a web 1166 00:37:09,030 --> 00:37:10,649 server that uses twentyfold descriptors, 1167 00:37:10,650 --> 00:37:12,149 how can you be certain that follow script 1168 00:37:12,150 --> 00:37:14,459 of 15 was actually the one that 1169 00:37:14,460 --> 00:37:15,659 corresponded with the network? 1170 00:37:15,660 --> 00:37:17,909 So maybe that was a log file or 1171 00:37:17,910 --> 00:37:19,409 it gets out of hand quickly. 1172 00:37:19,410 --> 00:37:21,539 So please don't use Cloud Abi in this 1173 00:37:21,540 --> 00:37:22,920 way. It's it's a mess. 1174 00:37:24,270 --> 00:37:26,369 And also a problem with this approach is 1175 00:37:26,370 --> 00:37:28,709 you really you sorry, lose 1176 00:37:28,710 --> 00:37:30,539 the existing paradigm where you can 1177 00:37:30,540 --> 00:37:32,369 specify complete applications from a 1178 00:37:32,370 --> 00:37:34,109 single configuration file. 1179 00:37:34,110 --> 00:37:36,419 Right now you can just go to EDC, made 1180 00:37:36,420 --> 00:37:38,219 changes to configuration file and restart 1181 00:37:38,220 --> 00:37:39,269 the service and it works. 1182 00:37:41,620 --> 00:37:43,269 If you would just started for Michele, 1183 00:37:43,270 --> 00:37:44,439 you would have maybe a separate 1184 00:37:44,440 --> 00:37:45,849 configuration file with program 1185 00:37:45,850 --> 00:37:47,709 attributes, but then you'd also need to 1186 00:37:47,710 --> 00:37:49,059 start up the Web server with all the 1187 00:37:49,060 --> 00:37:49,959 different file descriptors. 1188 00:37:49,960 --> 00:37:52,239 So it sort of turns 1189 00:37:52,240 --> 00:37:54,309 it into do so two different ways of 1190 00:37:54,310 --> 00:37:56,109 configuring the application, namely your 1191 00:37:56,110 --> 00:37:58,269 sort of configuration attributes 1192 00:37:58,270 --> 00:38:00,159 and follow script. So if you're thinking 1193 00:38:00,160 --> 00:38:01,539 about a way to sort of streamline this 1194 00:38:01,540 --> 00:38:02,919 process, to make it a lot easier and 1195 00:38:02,920 --> 00:38:04,559 safer and saner to start processes. 1196 00:38:04,560 --> 00:38:06,189 So I came up with a launch or two called 1197 00:38:06,190 --> 00:38:08,469 Cloud API Run, which is only 1198 00:38:08,470 --> 00:38:10,689 a couple of lines of sorry, 100 1199 00:38:10,690 --> 00:38:13,119 or 200 lines of C-code biggest, fairly 1200 00:38:13,120 --> 00:38:14,139 tiny. 1201 00:38:14,140 --> 00:38:17,109 And what it does, it sort of replaces 1202 00:38:17,110 --> 00:38:18,879 traditional string command line 1203 00:38:18,880 --> 00:38:21,489 arguments. So aragvi 1204 00:38:21,490 --> 00:38:23,739 by a tree structure that 1205 00:38:23,740 --> 00:38:25,570 semantically looks a lot like Yamal 1206 00:38:26,710 --> 00:38:27,710 and. 1207 00:38:28,340 --> 00:38:29,879 I'm just going to sort of explain in the 1208 00:38:29,880 --> 00:38:31,429 next couple of slides for what it looks 1209 00:38:31,430 --> 00:38:32,719 like, and then it sort of becomes more 1210 00:38:32,720 --> 00:38:34,369 obvious how it works. 1211 00:38:34,370 --> 00:38:36,109 So assume that you sort of have a 1212 00:38:36,110 --> 00:38:37,309 traditional Unix process. 1213 00:38:37,310 --> 00:38:39,379 So not a cloud API process that has a 1214 00:38:39,380 --> 00:38:41,089 YAML configuration file. 1215 00:38:41,090 --> 00:38:42,649 You could, for example, have a schematic, 1216 00:38:42,650 --> 00:38:43,549 looks a bit like this. 1217 00:38:43,550 --> 00:38:45,619 So you specify a hostname that's written 1218 00:38:45,620 --> 00:38:48,199 in error messages or log file entries, 1219 00:38:48,200 --> 00:38:49,819 a number of concurrent connections if it 1220 00:38:49,820 --> 00:38:52,189 has some kind of flat pool inside of it, 1221 00:38:52,190 --> 00:38:54,409 an IP IP address and board number, which 1222 00:38:54,410 --> 00:38:56,209 it needs to listen, a log file in the 1223 00:38:56,210 --> 00:38:58,489 root directory with cloud 1224 00:38:58,490 --> 00:39:00,619 API run. What you do is you sort 1225 00:39:00,620 --> 00:39:02,719 of annotate this fall in a special way 1226 00:39:02,720 --> 00:39:04,489 instead of just specifying these PAF 1227 00:39:04,490 --> 00:39:06,229 names directly like it did in this title 1228 00:39:06,230 --> 00:39:08,569 like this, IP addresses over there use 1229 00:39:08,570 --> 00:39:11,009 a special tag Yamas apparently 1230 00:39:11,010 --> 00:39:13,429 type language. I didn't really notice a 1231 00:39:13,430 --> 00:39:14,869 notice before I started working on this, 1232 00:39:14,870 --> 00:39:17,179 but I've just created a couple of custom 1233 00:39:17,180 --> 00:39:20,089 types tags that you can use to annotate 1234 00:39:20,090 --> 00:39:22,339 which strings are actually part names 1235 00:39:22,340 --> 00:39:24,409 and which strings are actually IP 1236 00:39:24,410 --> 00:39:26,359 addresses on which you need to bind. 1237 00:39:26,360 --> 00:39:27,829 So what happens is the quality of you I 1238 00:39:27,830 --> 00:39:30,379 run parses this YAML file, it 1239 00:39:30,380 --> 00:39:32,239 scans over all the entries in there. 1240 00:39:32,240 --> 00:39:33,889 It sees all those stock in the file tags 1241 00:39:33,890 --> 00:39:35,359 and then just replaces them by the actual 1242 00:39:35,360 --> 00:39:37,639 follow script of those directories and 1243 00:39:38,750 --> 00:39:40,429 network socket addresses. 1244 00:39:40,430 --> 00:39:42,499 So eventually end up with something 1245 00:39:42,500 --> 00:39:43,849 that looks like this, just like a 1246 00:39:43,850 --> 00:39:45,499 preprocessing pass that gets rid of all 1247 00:39:45,500 --> 00:39:47,209 of that stuff. And this is actually 1248 00:39:47,210 --> 00:39:48,139 what's being passed on to the 1249 00:39:48,140 --> 00:39:49,140 application. 1250 00:39:50,240 --> 00:39:52,309 So if you're writing a program instead of 1251 00:39:52,310 --> 00:39:53,989 using information, you can now use an 1252 00:39:53,990 --> 00:39:56,689 alternative prototype called programing. 1253 00:39:56,690 --> 00:39:59,059 And there is a set of functions provided 1254 00:39:59,060 --> 00:40:01,279 by an arc data header. 1255 00:40:01,280 --> 00:40:03,439 And these allow you to sort of 1256 00:40:03,440 --> 00:40:04,999 traverse over this data structure, 1257 00:40:05,000 --> 00:40:07,639 extract file descriptors from it, extract 1258 00:40:07,640 --> 00:40:09,679 scalar values like integers and strings 1259 00:40:09,680 --> 00:40:11,569 and booleans also allows you to sort of 1260 00:40:11,570 --> 00:40:13,579 iterate over all the maps and 1261 00:40:13,580 --> 00:40:15,469 dictionaries and all of the things that 1262 00:40:15,470 --> 00:40:17,239 are stored in that YAML file. 1263 00:40:17,240 --> 00:40:18,240 And 1264 00:40:19,370 --> 00:40:21,079 this is like a sort of a really nice 1265 00:40:21,080 --> 00:40:22,669 compromise, in my opinion, because it 1266 00:40:22,670 --> 00:40:24,319 doesn't make it harder to configure 1267 00:40:24,320 --> 00:40:26,509 services than the way it is right now. 1268 00:40:26,510 --> 00:40:28,039 You still have a single configuration 1269 00:40:28,040 --> 00:40:30,259 followed, allows you to sort of both add 1270 00:40:30,260 --> 00:40:32,089 configuration attributes, but also 1271 00:40:32,090 --> 00:40:33,589 resource dependencies that you want to 1272 00:40:33,590 --> 00:40:36,049 list. And it also makes it impossible 1273 00:40:36,050 --> 00:40:37,459 to sort of get the ordering of the file 1274 00:40:37,460 --> 00:40:39,079 descriptors wrong. Of course. 1275 00:40:39,080 --> 00:40:41,029 And what's also really nice of you I run 1276 00:40:41,030 --> 00:40:42,649 also ensures that all file descriptors 1277 00:40:42,650 --> 00:40:44,749 that happen to be open at the time but 1278 00:40:44,750 --> 00:40:46,939 weren't specified inside of this 1279 00:40:46,940 --> 00:40:49,009 YAML configuration file are closed. 1280 00:40:49,010 --> 00:40:50,779 So there's no longer any accidental 1281 00:40:50,780 --> 00:40:51,949 leakage of file descriptors into 1282 00:40:51,950 --> 00:40:54,079 processes for software 1283 00:40:54,080 --> 00:40:55,549 developers. That means that there's no 1284 00:40:55,550 --> 00:40:57,329 longer a need to write configuration file 1285 00:40:57,330 --> 00:40:59,059 Pasos. You can just use this data 1286 00:40:59,060 --> 00:41:01,129 structure to to sort 1287 00:41:01,130 --> 00:41:02,779 of browse through all the configuration 1288 00:41:02,780 --> 00:41:03,709 parameters. 1289 00:41:03,710 --> 00:41:05,299 And there's also no longer need to sort 1290 00:41:05,300 --> 00:41:07,369 of write code to acquire all those 1291 00:41:07,370 --> 00:41:08,629 resources and start startup, which is 1292 00:41:08,630 --> 00:41:10,579 nice. So once you're in programing, you 1293 00:41:10,580 --> 00:41:12,109 can already start working instead of 1294 00:41:12,110 --> 00:41:14,449 first having tens 1295 00:41:14,450 --> 00:41:16,099 of thousands of lines of parsing 1296 00:41:16,100 --> 00:41:17,839 configuration file and acquiring all the 1297 00:41:17,840 --> 00:41:19,030 resources to where you need them. 1298 00:41:20,630 --> 00:41:22,729 So now quickly go 1299 00:41:22,730 --> 00:41:24,329 like in the last remaining minutes that I 1300 00:41:24,330 --> 00:41:25,879 have, I'm going to explain some use cases 1301 00:41:25,880 --> 00:41:28,099 for cloud API that I've been thinking of. 1302 00:41:28,100 --> 00:41:29,899 Maybe the audience can think of some 1303 00:41:29,900 --> 00:41:31,969 other cool use cases 1304 00:41:31,970 --> 00:41:33,529 and I'd love to hear about that. 1305 00:41:33,530 --> 00:41:35,869 So at one of my previous employers, 1306 00:41:35,870 --> 00:41:37,939 I, I was working on some kind 1307 00:41:37,940 --> 00:41:40,189 of network security appliance and 1308 00:41:40,190 --> 00:41:42,109 one of the things we had was a spam 1309 00:41:42,110 --> 00:41:43,819 filter that was running on this and this 1310 00:41:43,820 --> 00:41:45,289 spam filter. We bought it from some kind 1311 00:41:45,290 --> 00:41:46,339 of third party vendor. 1312 00:41:46,340 --> 00:41:47,839 I don't even know the name of the company 1313 00:41:47,840 --> 00:41:48,840 anymore. 1314 00:41:50,790 --> 00:41:52,349 But the problem is that this is just a 1315 00:41:52,350 --> 00:41:53,999 unique process that's just running on 1316 00:41:54,000 --> 00:41:55,859 your hardware appliance, you know, it's 1317 00:41:55,860 --> 00:41:57,629 just a third party binary bulb that 1318 00:41:57,630 --> 00:41:58,529 you're running. 1319 00:41:58,530 --> 00:42:00,089 And what is this application was 1320 00:42:00,090 --> 00:42:02,199 implemented as a cloud API program, and 1321 00:42:02,200 --> 00:42:04,019 it wasn't modeled in a really simple way 1322 00:42:04,020 --> 00:42:06,299 where emails would be sent in on a pipe, 1323 00:42:06,300 --> 00:42:08,129 for example, and the application would 1324 00:42:08,130 --> 00:42:10,919 then just return a true or false 1325 00:42:10,920 --> 00:42:12,749 response, whether it was a spam email or 1326 00:42:12,750 --> 00:42:13,750 not. 1327 00:42:14,770 --> 00:42:16,059 That means that if there some kind of 1328 00:42:16,060 --> 00:42:18,579 buffer overflow in this spam filter, 1329 00:42:19,900 --> 00:42:22,419 email spam filter system, 1330 00:42:22,420 --> 00:42:24,819 then there's almost no impact 1331 00:42:24,820 --> 00:42:27,369 to it. The attacker can just sort of 1332 00:42:27,370 --> 00:42:29,379 consume some more CPU cycles on your 1333 00:42:29,380 --> 00:42:30,729 hardware appliance, but that's all it can 1334 00:42:30,730 --> 00:42:33,129 eventually do or maybe falsely return 1335 00:42:33,130 --> 00:42:34,389 that the email wasn't spam. 1336 00:42:34,390 --> 00:42:35,919 But the question is whether that's a 1337 00:42:35,920 --> 00:42:37,269 really bad thing. It's still better than 1338 00:42:37,270 --> 00:42:39,339 just, you know, eventually maybe 1339 00:42:39,340 --> 00:42:40,539 even becoming root on this 1340 00:42:41,560 --> 00:42:43,629 hardware appliance. 1341 00:42:43,630 --> 00:42:45,139 Same old for network appliances. 1342 00:42:45,140 --> 00:42:46,869 There's a lot of research right now 1343 00:42:46,870 --> 00:42:47,870 towards doing 1344 00:42:48,940 --> 00:42:51,489 pacard filtering and userspace, 1345 00:42:51,490 --> 00:42:53,139 for example. NetApp is one of those 1346 00:42:53,140 --> 00:42:54,639 projects where you can really efficiently 1347 00:42:54,640 --> 00:42:56,739 get network packets into userspace 1348 00:42:56,740 --> 00:42:58,629 and implement all of the firewall logic 1349 00:42:58,630 --> 00:43:00,489 and userspace and then send a message 1350 00:43:00,490 --> 00:43:01,689 back to the kernel whether the package 1351 00:43:01,690 --> 00:43:03,309 should be accepted or rejected. 1352 00:43:03,310 --> 00:43:04,719 Something like this could also be run as 1353 00:43:04,720 --> 00:43:06,679 a cloud API application to just make a 1354 00:43:06,680 --> 00:43:07,680 lot more secure. 1355 00:43:09,380 --> 00:43:11,089 So high level question management, this 1356 00:43:11,090 --> 00:43:12,319 is also a really interesting one, in my 1357 00:43:12,320 --> 00:43:14,649 opinion, by applications 1358 00:43:14,650 --> 00:43:16,159 have the property that the dependencies 1359 00:43:16,160 --> 00:43:17,539 of them are sort of really known up 1360 00:43:17,540 --> 00:43:18,549 front. 1361 00:43:18,550 --> 00:43:19,879 It's not as if they start up and then 1362 00:43:19,880 --> 00:43:21,149 acquire the resources themselves. 1363 00:43:21,150 --> 00:43:22,849 You already know what they they they 1364 00:43:22,850 --> 00:43:24,949 depend on so far, some kind of custom 1365 00:43:24,950 --> 00:43:26,209 management system. This would also be 1366 00:43:26,210 --> 00:43:27,109 really nice. 1367 00:43:27,110 --> 00:43:29,089 You have a couple of web front end 1368 00:43:29,090 --> 00:43:31,040 applications, a database back, some 1369 00:43:32,180 --> 00:43:34,039 batch jobs, and all of those have to 1370 00:43:34,040 --> 00:43:35,959 dependencies that you can sort of express 1371 00:43:35,960 --> 00:43:36,889 in a graph. 1372 00:43:36,890 --> 00:43:38,389 And based on that graph, the cluster 1373 00:43:38,390 --> 00:43:39,829 management system can start them up in 1374 00:43:39,830 --> 00:43:40,789 the right order. 1375 00:43:40,790 --> 00:43:42,529 And sure, that they're sort of started up 1376 00:43:42,530 --> 00:43:43,429 close to each other. 1377 00:43:43,430 --> 00:43:45,169 So not that, for example, the database 1378 00:43:45,170 --> 00:43:46,789 back end is started up in a data center 1379 00:43:46,790 --> 00:43:48,799 in Japan while the Web front lines are 1380 00:43:48,800 --> 00:43:50,209 started up in the data center here in 1381 00:43:50,210 --> 00:43:51,949 Germany. You can really improve the 1382 00:43:51,950 --> 00:43:54,169 locality if you sort of old if you know 1383 00:43:54,170 --> 00:43:55,429 all that information up front. 1384 00:43:57,650 --> 00:43:59,479 It also makes migration of processes a 1385 00:43:59,480 --> 00:44:00,799 bit easier because you actually know what 1386 00:44:00,800 --> 00:44:01,829 the process depends on. 1387 00:44:01,830 --> 00:44:03,259 So you know what? You need to migrate to 1388 00:44:03,260 --> 00:44:04,300 the honor system as well. 1389 00:44:06,420 --> 00:44:08,489 And sort of this is really looking 1390 00:44:08,490 --> 00:44:09,959 really far ahead and, you know, the 1391 00:44:09,960 --> 00:44:11,399 question is whether it's ever going to 1392 00:44:11,400 --> 00:44:13,079 happen, of course. But still, I like to 1393 00:44:13,080 --> 00:44:14,080 dream about this. 1394 00:44:15,090 --> 00:44:16,429 There's this service called the Amazon, 1395 00:44:16,430 --> 00:44:17,769 the EU and Amazon, etc. 1396 00:44:17,770 --> 00:44:19,859 is really nice in my opinion, 1397 00:44:19,860 --> 00:44:22,949 that you can just run arbitrary 1398 00:44:22,950 --> 00:44:24,239 Unix programs in the cloud. 1399 00:44:24,240 --> 00:44:26,279 It doesn't really matter which program 1400 00:44:26,280 --> 00:44:27,479 language they're written in. 1401 00:44:27,480 --> 00:44:29,699 You can just create your own Linux 1402 00:44:29,700 --> 00:44:31,859 VM and just run a Web 1403 00:44:31,860 --> 00:44:33,959 server service written in Rust or 1404 00:44:33,960 --> 00:44:35,129 whatever you like. 1405 00:44:35,130 --> 00:44:36,899 Google app engine on the other end is 1406 00:44:36,900 --> 00:44:38,399 sort of a more Manwich system where you 1407 00:44:38,400 --> 00:44:40,199 just build your own application, either 1408 00:44:40,200 --> 00:44:41,849 Python, Jafo or go. 1409 00:44:41,850 --> 00:44:43,769 You just throw it over the fence and they 1410 00:44:43,770 --> 00:44:45,779 start it up for you and automatically 1411 00:44:45,780 --> 00:44:46,919 scale it up. 1412 00:44:46,920 --> 00:44:49,039 And already sort of 1413 00:44:49,040 --> 00:44:50,969 if a system goes down, they automatically 1414 00:44:50,970 --> 00:44:52,139 start it up on a different system. 1415 00:44:52,140 --> 00:44:53,639 So it's a lot more menaged. 1416 00:44:53,640 --> 00:44:55,709 And I think the Cloud API could be used 1417 00:44:55,710 --> 00:44:57,389 to sort of combine the two of these where 1418 00:44:57,390 --> 00:44:59,669 you sort of had a more managed system 1419 00:44:59,670 --> 00:45:01,079 where you don't actually care about 1420 00:45:01,080 --> 00:45:02,729 individual Linux or unique systems 1421 00:45:02,730 --> 00:45:04,799 anymore, but it still allows you 1422 00:45:04,800 --> 00:45:06,479 to just build programs in any programing 1423 00:45:06,480 --> 00:45:07,530 language you like. So 1424 00:45:08,640 --> 00:45:10,019 maybe we'll see something like this in 1425 00:45:10,020 --> 00:45:11,579 the future appear would be pretty 1426 00:45:11,580 --> 00:45:12,580 awesome. 1427 00:45:13,140 --> 00:45:14,639 So this is all I have to say for now 1428 00:45:14,640 --> 00:45:16,619 because we're sort of way out of time. 1429 00:45:16,620 --> 00:45:18,779 I guess here are a couple of things that 1430 00:45:18,780 --> 00:45:20,579 are interesting. So first of all, there's 1431 00:45:20,580 --> 00:45:22,889 a link to my sort of consulting company's 1432 00:45:22,890 --> 00:45:24,839 website. But on that site, you can also 1433 00:45:24,840 --> 00:45:26,789 find documentation of how to use this. 1434 00:45:26,790 --> 00:45:28,029 All of this is open source. 1435 00:45:28,030 --> 00:45:29,189 So here at the bottom are a couple of 1436 00:45:29,190 --> 00:45:31,379 links to my guitar page for 1437 00:45:31,380 --> 00:45:33,509 my company. So the top link is to the C 1438 00:45:33,510 --> 00:45:35,009 library that you need to use for cloud 1439 00:45:35,010 --> 00:45:36,779 API. And the bottom one is the package 1440 00:45:36,780 --> 00:45:38,669 collection. So if you browse through the 1441 00:45:38,670 --> 00:45:39,989 package collection and you see that some 1442 00:45:39,990 --> 00:45:41,429 kind of package is missing that you like. 1443 00:45:42,500 --> 00:45:44,509 Well, then, if you're really into that 1444 00:45:44,510 --> 00:45:46,609 stuff, then, you know, you can always 1445 00:45:46,610 --> 00:45:48,559 let me pull requests and get out. 1446 00:45:48,560 --> 00:45:50,339 And there's also an IOC channel clouded 1447 00:45:50,340 --> 00:45:52,369 Beliefnet. So if you'd like to look 1448 00:45:52,370 --> 00:45:53,899 around, then that's a place you can go 1449 00:45:53,900 --> 00:45:55,429 to. And that's all I have to say for now. 1450 00:45:55,430 --> 00:45:56,449 Thanks for attending my talk. 1451 00:46:07,400 --> 00:46:08,989 Thank you very much. 1452 00:46:08,990 --> 00:46:11,209 If you have questions, please line up 1453 00:46:11,210 --> 00:46:13,459 behind the four microphones we have here. 1454 00:46:13,460 --> 00:46:16,579 Are there questions from Iasi Bono? 1455 00:46:16,580 --> 00:46:18,739 No questions from IREs, no questions from 1456 00:46:18,740 --> 00:46:19,740 Iasi. 1457 00:46:20,450 --> 00:46:22,729 We'll start with the microphone in the 1458 00:46:22,730 --> 00:46:23,730 left. 1459 00:46:26,850 --> 00:46:28,879 OK, thank you for your talk. 1460 00:46:28,880 --> 00:46:30,799 One of the problems you mentioned was 1461 00:46:30,800 --> 00:46:32,959 that a lot of primitives 1462 00:46:32,960 --> 00:46:34,879 we use, for instance, in 1463 00:46:36,200 --> 00:46:38,329 C libraries are 1464 00:46:38,330 --> 00:46:39,769 that you are dependent 1465 00:46:42,080 --> 00:46:44,209 from a global state of the system 1466 00:46:44,210 --> 00:46:46,519 for for instance, it's C local 1467 00:46:46,520 --> 00:46:48,749 time, but maybe it's 1468 00:46:48,750 --> 00:46:51,079 the result that that comes or everything 1469 00:46:51,080 --> 00:46:53,209 like that. So I'm sorry, could you repeat 1470 00:46:53,210 --> 00:46:54,209 that question? Yeah. 1471 00:46:54,210 --> 00:46:56,689 So how do you solve this problem 1472 00:46:56,690 --> 00:46:59,569 of being dependent of a global state 1473 00:46:59,570 --> 00:47:02,409 of the system in its CEO, 1474 00:47:03,650 --> 00:47:05,599 for instance, c local teams that you 1475 00:47:05,600 --> 00:47:06,469 mentioned or. 1476 00:47:06,470 --> 00:47:08,479 Yeah, so that's a really good question. 1477 00:47:08,480 --> 00:47:09,799 So and so. 1478 00:47:09,800 --> 00:47:12,019 So first of all, I, I do 1479 00:47:12,020 --> 00:47:14,179 realize that systems will always 1480 00:47:14,180 --> 00:47:16,249 have global state in them and trying 1481 00:47:16,250 --> 00:47:18,319 to eliminate that is just far too 1482 00:47:18,320 --> 00:47:19,219 optimistic. 1483 00:47:19,220 --> 00:47:21,319 But what I think is if at the 1484 00:47:21,320 --> 00:47:23,359 very sort of bottom, if you look at sort 1485 00:47:23,360 --> 00:47:25,219 of the core primitives that are exported 1486 00:47:25,220 --> 00:47:27,019 by the operating system, they should not 1487 00:47:27,020 --> 00:47:29,239 be bound to any global state 1488 00:47:29,240 --> 00:47:31,159 global status, easier to introduce and to 1489 00:47:31,160 --> 00:47:32,129 eliminate. 1490 00:47:32,130 --> 00:47:34,639 And if you have sort of an 1491 00:47:34,640 --> 00:47:36,889 environment where there is global state, 1492 00:47:36,890 --> 00:47:39,049 for example, there is a workstation that 1493 00:47:39,050 --> 00:47:41,359 has a login session that has a menu 1494 00:47:41,360 --> 00:47:43,039 bar at the top or something like that, 1495 00:47:43,040 --> 00:47:44,659 it's always easier to introduce it in a 1496 00:47:44,660 --> 00:47:46,489 programing userspace than it is to sort 1497 00:47:46,490 --> 00:47:48,829 of already let a trickle 1498 00:47:48,830 --> 00:47:50,719 through through the core APIs of the 1499 00:47:50,720 --> 00:47:52,009 operating system, because that's the 1500 00:47:52,010 --> 00:47:53,639 reason why we need virtualization and 1501 00:47:53,640 --> 00:47:55,699 sort of really trickled into the APIs. 1502 00:47:55,700 --> 00:47:57,109 And now applications really depend on the 1503 00:47:57,110 --> 00:47:58,279 global stage. 1504 00:47:58,280 --> 00:48:00,199 So I'm not saying we can eliminate it, 1505 00:48:00,200 --> 00:48:02,449 but it shouldn't be part of the core 1506 00:48:02,450 --> 00:48:03,450 API. 1507 00:48:04,400 --> 00:48:05,479 Did it answer your question? 1508 00:48:05,480 --> 00:48:07,969 Yeah. So if you develop a 1509 00:48:07,970 --> 00:48:08,970 cloud 1510 00:48:12,500 --> 00:48:14,869 application, how do you get to the local 1511 00:48:14,870 --> 00:48:16,159 time? 1512 00:48:16,160 --> 00:48:18,259 You have to personalize 1513 00:48:18,260 --> 00:48:19,939 local time in the. 1514 00:48:19,940 --> 00:48:21,349 Yeah. So for example, it could be the 1515 00:48:21,350 --> 00:48:23,479 case that your configuration 1516 00:48:23,480 --> 00:48:25,099 file for your application is like a time 1517 00:48:25,100 --> 00:48:27,559 zone, Kolon, Europe's Amsterdam 1518 00:48:27,560 --> 00:48:29,239 or Europe's Lightburn, et cetera. 1519 00:48:29,240 --> 00:48:31,699 And then inside of your application 1520 00:48:31,700 --> 00:48:33,379 you use that time zone instead of being 1521 00:48:33,380 --> 00:48:34,709 stuck to a global times and that 1522 00:48:34,710 --> 00:48:36,020 specified in such EDC. 1523 00:48:38,500 --> 00:48:40,629 The microphone from the right place, 1524 00:48:40,630 --> 00:48:41,429 yes, over there. 1525 00:48:41,430 --> 00:48:43,779 Hello, can you hear me OK? 1526 00:48:43,780 --> 00:48:45,999 Yes, I can hear. So you mentioned 1527 00:48:46,000 --> 00:48:47,859 you started with a clean slate. 1528 00:48:47,860 --> 00:48:49,840 It was definitely partial clean slate. 1529 00:48:50,920 --> 00:48:53,409 Cherryholmes is a Cambridge University 1530 00:48:53,410 --> 00:48:55,389 project. They made their own custom risk 1531 00:48:55,390 --> 00:48:57,579 architecture with Custom Memory 1532 00:48:57,580 --> 00:49:00,009 Management Unit, which can protect region 1533 00:49:00,010 --> 00:49:02,289 of memory known as a capability. 1534 00:49:02,290 --> 00:49:04,539 And then at they have a custom 1535 00:49:04,540 --> 00:49:06,399 operating system and a custom programing 1536 00:49:06,400 --> 00:49:08,559 language, which then every time 1537 00:49:08,560 --> 00:49:10,839 the instantiate an object, it's coupled 1538 00:49:10,840 --> 00:49:13,029 not with just information, 1539 00:49:13,030 --> 00:49:15,219 but also authority know 1540 00:49:15,220 --> 00:49:17,349 capabilities to perform some action on 1541 00:49:17,350 --> 00:49:18,350 a resource. 1542 00:49:19,060 --> 00:49:21,309 And this actually gives you a 1543 00:49:21,310 --> 00:49:23,529 multiplicative attack 1544 00:49:23,530 --> 00:49:26,019 surface area reduction because every 1545 00:49:26,020 --> 00:49:28,059 abstraction layer of your program, you're 1546 00:49:28,060 --> 00:49:30,489 reducing attack surface area. 1547 00:49:30,490 --> 00:49:32,739 Yeah, this is 1548 00:49:32,740 --> 00:49:34,869 like kind of like halfway 1549 00:49:34,870 --> 00:49:36,789 or partial way there. 1550 00:49:36,790 --> 00:49:38,859 It's definitely implement some 1551 00:49:38,860 --> 00:49:41,319 capability, object 1552 00:49:41,320 --> 00:49:44,289 capability, security, but not 1553 00:49:44,290 --> 00:49:45,759 the full thing. 1554 00:49:45,760 --> 00:49:47,739 So so it's really awesome that you 1555 00:49:47,740 --> 00:49:50,289 brought up a cherry. 1556 00:49:50,290 --> 00:49:52,389 So I actually know that 1557 00:49:52,390 --> 00:49:53,949 the people working on Cherry pretty well. 1558 00:49:53,950 --> 00:49:56,439 I'm very thoroughly 1559 00:49:56,440 --> 00:49:57,909 involved with, like, you know, I checked 1560 00:49:57,910 --> 00:49:59,289 with at least a couple of them people 1561 00:49:59,290 --> 00:50:00,279 once every couple of weeks. 1562 00:50:00,280 --> 00:50:01,719 I hear all that news coming in. 1563 00:50:01,720 --> 00:50:03,819 And so what the cherry 1564 00:50:03,820 --> 00:50:05,049 people are doing is they're building a 1565 00:50:05,050 --> 00:50:07,209 CPU that has capability 1566 00:50:07,210 --> 00:50:08,439 registers built in. 1567 00:50:08,440 --> 00:50:10,029 So instead of having operating system 1568 00:50:10,030 --> 00:50:11,319 level capabilities where you have 1569 00:50:11,320 --> 00:50:12,789 followed the script resecting 1570 00:50:12,790 --> 00:50:15,399 capabilities, you can actually say, 1571 00:50:15,400 --> 00:50:17,109 you know, I here have a tiny piece of 1572 00:50:17,110 --> 00:50:19,329 memory, a buffer where an application 1573 00:50:19,330 --> 00:50:21,279 can right into. But now I'm removing the 1574 00:50:21,280 --> 00:50:22,779 the right bit from the piece of memory 1575 00:50:22,780 --> 00:50:24,579 and passing that onto some other thread 1576 00:50:24,580 --> 00:50:26,229 or code routine inside of the process, if 1577 00:50:26,230 --> 00:50:27,519 I understand correctly. 1578 00:50:27,520 --> 00:50:29,799 And I mean, it would be really awesome 1579 00:50:29,800 --> 00:50:31,899 if like cherry and cloudy I 1580 00:50:31,900 --> 00:50:33,579 had children, that would be the most 1581 00:50:33,580 --> 00:50:34,580 awesome thing ever. 1582 00:50:35,440 --> 00:50:38,409 And it's really cool because I'm 1583 00:50:38,410 --> 00:50:40,149 maybe, you know, Bruce Davis, who's a 1584 00:50:40,150 --> 00:50:42,519 freebees developer as well, actually. 1585 00:50:42,520 --> 00:50:44,949 Actually, I work on TAHO laughs, 1586 00:50:44,950 --> 00:50:46,569 which is a cryptographic capability 1587 00:50:46,570 --> 00:50:48,189 system, OK? 1588 00:50:48,190 --> 00:50:50,079 And it has a different security model 1589 00:50:50,080 --> 00:50:51,229 that works over network. 1590 00:50:51,230 --> 00:50:52,129 So you're saying the cloud. 1591 00:50:52,130 --> 00:50:53,619 Maybe I should have kids with that. 1592 00:50:54,730 --> 00:50:56,289 Yeah. Yeah, potentially. 1593 00:50:56,290 --> 00:50:58,449 OK, well we should chat 1594 00:50:58,450 --> 00:51:00,669 afterwards. I just wanted to like 1595 00:51:00,670 --> 00:51:02,979 mention that my different 1596 00:51:02,980 --> 00:51:03,729 perspective. Hm. 1597 00:51:03,730 --> 00:51:06,159 Yeah. Yeah. I mean yeah 1598 00:51:06,160 --> 00:51:07,389 it's really cool that you mentioned that 1599 00:51:07,390 --> 00:51:09,279 because I mean just look it up Cherry. 1600 00:51:09,280 --> 00:51:10,989 It's also developed by the University of 1601 00:51:10,990 --> 00:51:12,009 Cambridge. 1602 00:51:12,010 --> 00:51:13,599 Really awesome project. 1603 00:51:13,600 --> 00:51:14,799 Cool. 1604 00:51:14,800 --> 00:51:16,659 Next question from the front left 1605 00:51:16,660 --> 00:51:18,369 microphone followed by the front right 1606 00:51:18,370 --> 00:51:20,919 microphone up front 1607 00:51:20,920 --> 00:51:23,199 rear left microphone, rear 1608 00:51:23,200 --> 00:51:25,179 left microphone first, first a front 1609 00:51:25,180 --> 00:51:27,249 left, then the rear 1610 00:51:27,250 --> 00:51:29,259 me or OK. 1611 00:51:29,260 --> 00:51:32,319 Oh so the question about time more 1612 00:51:32,320 --> 00:51:34,119 remark than the question. 1613 00:51:34,120 --> 00:51:36,399 So I don't know what your model but 1614 00:51:36,400 --> 00:51:38,709 actually providing the ability 1615 00:51:38,710 --> 00:51:40,989 to read the time can be a dangerous 1616 00:51:40,990 --> 00:51:42,219 because you know, 1617 00:51:43,360 --> 00:51:44,360 Glock's 1618 00:51:45,580 --> 00:51:47,799 kind of unique and hard of hardware 1619 00:51:47,800 --> 00:51:50,439 details and it can be 1620 00:51:50,440 --> 00:51:52,689 used to identify the machine. 1621 00:51:52,690 --> 00:51:53,829 Yeah. Yeah. 1622 00:51:53,830 --> 00:51:55,329 So this is also really good. 1623 00:51:55,330 --> 00:51:57,669 Remarque So I have to say that I'm, 1624 00:51:57,670 --> 00:52:00,039 you know, famous last words, 1625 00:52:00,040 --> 00:52:02,199 even Cloud Abi is not perfect. 1626 00:52:02,200 --> 00:52:03,519 So, for example, the fact is you can 1627 00:52:03,520 --> 00:52:05,679 access those clocks. And the reason 1628 00:52:05,680 --> 00:52:07,269 that I have for this is to following. 1629 00:52:07,270 --> 00:52:09,399 So POSIX has already a nice 1630 00:52:09,400 --> 00:52:11,859 standardized interface for dealing 1631 00:52:11,860 --> 00:52:14,049 with directories as file 1632 00:52:14,050 --> 00:52:16,109 descriptors. So open at the system called 1633 00:52:16,110 --> 00:52:18,039 that I mentioned in these slides is 1634 00:52:18,040 --> 00:52:20,289 actually part of POSIX 2008. 1635 00:52:20,290 --> 00:52:22,479 And with that in mind, I could sort 1636 00:52:22,480 --> 00:52:23,949 of think that there's a reasonable sort 1637 00:52:23,950 --> 00:52:26,199 of way I can expect 1638 00:52:26,200 --> 00:52:27,609 people to adopt this. 1639 00:52:27,610 --> 00:52:29,529 The problem of Klok APIs is it would be 1640 00:52:29,530 --> 00:52:31,659 really awesome if there was also really a 1641 00:52:31,660 --> 00:52:33,309 way where you can say, I want to pass on 1642 00:52:33,310 --> 00:52:34,659 a fake LOC to this application. 1643 00:52:34,660 --> 00:52:36,789 This application is not running in 2015, 1644 00:52:36,790 --> 00:52:38,859 but in the future or the past 1645 00:52:38,860 --> 00:52:41,410 could even be useful for testing 2058 1646 00:52:42,700 --> 00:52:43,779 compliance bugs. 1647 00:52:43,780 --> 00:52:45,669 You know, but the problem is there is no 1648 00:52:45,670 --> 00:52:47,649 sort of standardized API for this. 1649 00:52:47,650 --> 00:52:49,839 So right now, 1650 00:52:49,840 --> 00:52:51,159 to sort of make the adoption go a lot 1651 00:52:51,160 --> 00:52:53,739 faster and not sort of cause a lot of 1652 00:52:53,740 --> 00:52:56,319 bike sharing and trolling, I 1653 00:52:56,320 --> 00:52:58,089 decided to just stick to a subset of 1654 00:52:58,090 --> 00:52:59,739 Unix. And unfortunately, that doesn't 1655 00:52:59,740 --> 00:53:02,169 provide any way to inject custom 1656 00:53:02,170 --> 00:53:04,389 random number generators or random clocks 1657 00:53:04,390 --> 00:53:05,799 or that kind of stuff. 1658 00:53:05,800 --> 00:53:07,689 Yeah, but but it's a really good remark. 1659 00:53:07,690 --> 00:53:09,309 Yeah. Thank you. 1660 00:53:09,310 --> 00:53:11,349 The left rear microphone, please. 1661 00:53:14,670 --> 00:53:16,979 OK, there you are. 1662 00:53:16,980 --> 00:53:19,079 How does a capability based security 1663 00:53:19,080 --> 00:53:20,999 model play with IPC, especially when 1664 00:53:21,000 --> 00:53:23,039 there's no parent child relation between 1665 00:53:23,040 --> 00:53:24,040 the processes? 1666 00:53:25,350 --> 00:53:26,689 Sorry, could you repeat the question? 1667 00:53:26,690 --> 00:53:29,069 OK, how does your capability 1668 00:53:29,070 --> 00:53:30,719 based security model play with the entire 1669 00:53:30,720 --> 00:53:32,729 process communication, especially when 1670 00:53:32,730 --> 00:53:34,799 there's no parent child 1671 00:53:34,800 --> 00:53:36,719 relation between the processes? 1672 00:53:38,190 --> 00:53:40,229 Well, I mean, so. 1673 00:53:41,460 --> 00:53:43,289 Now, I need to bring up like a list of 1674 00:53:43,290 --> 00:53:46,199 all the individual 1675 00:53:46,200 --> 00:53:48,509 requirements or, you know, 1676 00:53:48,510 --> 00:53:51,209 axioms that sort of specify 1677 00:53:51,210 --> 00:53:52,589 what a capability based security system 1678 00:53:52,590 --> 00:53:54,839 is, but there is 1679 00:53:54,840 --> 00:53:55,840 a way of. 1680 00:53:57,100 --> 00:53:59,229 If I if my interpretation of Kapiti based 1681 00:53:59,230 --> 00:54:01,149 security is correct, eventually what it 1682 00:54:01,150 --> 00:54:02,739 boils down to is that every program on 1683 00:54:02,740 --> 00:54:04,989 its own has its own bag 1684 00:54:04,990 --> 00:54:06,909 of tokens that it holds onto its own 1685 00:54:06,910 --> 00:54:09,399 capabilities. And it's in Cloud-based 1686 00:54:09,400 --> 00:54:10,989 case file descriptors. 1687 00:54:10,990 --> 00:54:13,149 And every process can do a couple 1688 00:54:13,150 --> 00:54:14,769 of things with those file descriptors. 1689 00:54:14,770 --> 00:54:16,839 Namely, it can discard those file 1690 00:54:16,840 --> 00:54:17,979 descriptors at free will. 1691 00:54:17,980 --> 00:54:19,149 You can just close your own file 1692 00:54:19,150 --> 00:54:21,109 descriptors and you can actually pass 1693 00:54:21,110 --> 00:54:22,779 them on to different processes. 1694 00:54:22,780 --> 00:54:24,699 And there might be some other different 1695 00:54:24,700 --> 00:54:27,039 requirements or some other 1696 00:54:27,040 --> 00:54:28,299 properties in there as well. 1697 00:54:28,300 --> 00:54:29,300 But 1698 00:54:31,060 --> 00:54:33,399 is this not a capability based system? 1699 00:54:33,400 --> 00:54:34,400 That's my question. 1700 00:54:35,470 --> 00:54:36,580 What's what's 1701 00:54:37,630 --> 00:54:39,729 in your if you missing, can 1702 00:54:39,730 --> 00:54:41,799 you use the capability based security 1703 00:54:41,800 --> 00:54:43,929 system to to secure or to 1704 00:54:43,930 --> 00:54:46,779 control entire process communication? 1705 00:54:46,780 --> 00:54:49,059 Um, well, 1706 00:54:49,060 --> 00:54:50,949 I think you're referring to the fact that 1707 00:54:50,950 --> 00:54:52,599 with there's also this thing that 1708 00:54:53,740 --> 00:54:56,409 it might be possible to sort of 1709 00:54:56,410 --> 00:54:58,179 steal tokens from a process where you can 1710 00:54:58,180 --> 00:55:00,549 say, I now want to sort of disallow 1711 00:55:00,550 --> 00:55:02,619 this process from accessing X, 1712 00:55:02,620 --> 00:55:03,620 and there is no 1713 00:55:04,690 --> 00:55:05,929 support for that at all. 1714 00:55:05,930 --> 00:55:08,079 So you start up a process and you granted 1715 00:55:08,080 --> 00:55:09,579 these tokens, but there's no way to 1716 00:55:09,580 --> 00:55:11,709 actually retract them later on that's 1717 00:55:11,710 --> 00:55:13,089 missing from this environment. 1718 00:55:13,090 --> 00:55:14,619 But if you just make sure that you start 1719 00:55:14,620 --> 00:55:16,099 your process up with the right set of 1720 00:55:16,100 --> 00:55:18,309 file descriptors where you don't leak 1721 00:55:18,310 --> 00:55:19,479 any things that the process shouldn't 1722 00:55:19,480 --> 00:55:20,889 have access to, then I think you should 1723 00:55:20,890 --> 00:55:21,890 already be quite cheap. 1724 00:55:24,200 --> 00:55:26,329 We have a question from Iasi, We are 1725 00:55:26,330 --> 00:55:27,199 a signal angel. 1726 00:55:27,200 --> 00:55:29,359 Yeah, how is this and rights 1727 00:55:29,360 --> 00:55:31,699 different from Dhaka, which is at the 1728 00:55:31,700 --> 00:55:33,799 end its base also only 1729 00:55:33,800 --> 00:55:36,199 true to stereo's 1730 00:55:36,200 --> 00:55:38,599 as I didn't understand the question 1731 00:55:38,600 --> 00:55:39,600 completely. 1732 00:55:41,240 --> 00:55:43,279 Do you hear me OK? 1733 00:55:43,280 --> 00:55:45,649 How is how is this rights 1734 00:55:45,650 --> 00:55:47,869 management different from Dhaka, which is 1735 00:55:47,870 --> 00:55:50,359 at its base also only 1736 00:55:50,360 --> 00:55:52,580 C.H. Road and tell you it's. 1737 00:55:54,540 --> 00:55:55,800 Um, so 1738 00:55:57,330 --> 00:55:58,859 I have to confess, there are a lot of 1739 00:55:58,860 --> 00:56:00,359 different operating systems out there and 1740 00:56:00,360 --> 00:56:02,429 all use capability based security in a 1741 00:56:02,430 --> 00:56:03,809 different way. 1742 00:56:03,810 --> 00:56:05,759 I think what cloud is what makes Cloud 1743 00:56:05,760 --> 00:56:07,619 API unique is that, first of all, it's 1744 00:56:07,620 --> 00:56:09,749 based on the POSIX APIs 1745 00:56:09,750 --> 00:56:11,189 for which there's already a whole bunch 1746 00:56:11,190 --> 00:56:13,139 of existing software available. 1747 00:56:13,140 --> 00:56:15,269 And compared to capsicum, 1748 00:56:15,270 --> 00:56:16,919 it has the advantage of sort of having 1749 00:56:16,920 --> 00:56:17,999 less food shooting. 1750 00:56:18,000 --> 00:56:19,000 So, 1751 00:56:20,280 --> 00:56:22,019 yes, there might be some other systems 1752 00:56:22,020 --> 00:56:23,849 that also sort of have a huge overlap in 1753 00:56:23,850 --> 00:56:25,739 functionality with this, but sort of. 1754 00:56:25,740 --> 00:56:28,049 Exactly. Focusing on making bosak stuff 1755 00:56:28,050 --> 00:56:30,299 work is actually where sort of the the 1756 00:56:30,300 --> 00:56:31,800 niche market is in this case. 1757 00:56:34,280 --> 00:56:36,229 We have a question from the microphone 1758 00:56:36,230 --> 00:56:37,230 from left 1759 00:56:38,540 --> 00:56:40,609 of most of the things 1760 00:56:40,610 --> 00:56:42,769 normally people today would do with 1761 00:56:42,770 --> 00:56:43,699 namespace. 1762 00:56:43,700 --> 00:56:45,230 So username spazzes, 1763 00:56:46,490 --> 00:56:49,219 network name spaces or 1764 00:56:49,220 --> 00:56:51,559 boundary lines and containers 1765 00:56:51,560 --> 00:56:53,629 like Takeda's screws up 1766 00:56:53,630 --> 00:56:55,999 only one thing which username 1767 00:56:56,000 --> 00:56:58,429 spaces which are coming soon 1768 00:56:58,430 --> 00:57:01,069 since two years now 1769 00:57:01,070 --> 00:57:03,439 and actually years as a kernel 1770 00:57:03,440 --> 00:57:04,440 hack. 1771 00:57:05,290 --> 00:57:07,539 To introduce username space into 1772 00:57:07,540 --> 00:57:09,969 the colonel has to touch 1773 00:57:09,970 --> 00:57:12,099 150 pieces 1774 00:57:12,100 --> 00:57:13,839 in the kernel and one of our developers 1775 00:57:13,840 --> 00:57:16,089 is working on this, but it's not 1776 00:57:16,090 --> 00:57:18,279 yet finished. So normally, 1777 00:57:18,280 --> 00:57:20,109 I would say if I have a critical 1778 00:57:20,110 --> 00:57:22,299 application, I would try to do 1779 00:57:22,300 --> 00:57:24,549 it and the user was a different user 1780 00:57:24,550 --> 00:57:26,769 and take away the rights of 1781 00:57:26,770 --> 00:57:27,729 this user. 1782 00:57:27,730 --> 00:57:30,459 And this is very similar to to this 1783 00:57:30,460 --> 00:57:33,079 kind of things of of of 1784 00:57:33,080 --> 00:57:34,899 CONTAINERIZE applications. 1785 00:57:34,900 --> 00:57:36,999 And I have all the. 1786 00:57:38,570 --> 00:57:40,729 All the things that I do not 1787 00:57:40,730 --> 00:57:42,319 even have to modify the application, 1788 00:57:42,320 --> 00:57:44,509 which might be hard, so if you have 1789 00:57:44,510 --> 00:57:46,399 to make you mention Java, give me a Java 1790 00:57:46,400 --> 00:57:48,379 binary which really accepts this file 1791 00:57:48,380 --> 00:57:50,959 descriptors, then 1792 00:57:50,960 --> 00:57:51,919 everybody would be happy. 1793 00:57:51,920 --> 00:57:53,239 But I've not seen that so far. 1794 00:57:53,240 --> 00:57:55,339 Yeah, so so I think that there 1795 00:57:55,340 --> 00:57:56,340 is sort of like a. 1796 00:57:58,330 --> 00:58:00,819 A divide or like like division 1797 00:58:00,820 --> 00:58:02,889 that sort of puts people into two camps 1798 00:58:02,890 --> 00:58:04,989 right now. So first of all, there is 1799 00:58:04,990 --> 00:58:07,359 this focus on switching towards 1800 00:58:07,360 --> 00:58:09,309 capability based systems, which I've 1801 00:58:09,310 --> 00:58:10,449 explained in this talk. 1802 00:58:10,450 --> 00:58:11,829 But then on the other hand, there's also 1803 00:58:11,830 --> 00:58:13,899 sort of a movement that's moving towards 1804 00:58:13,900 --> 00:58:15,699 virtualizing name spaces. 1805 00:58:15,700 --> 00:58:17,949 So that includes both FreeBSD jails, 1806 00:58:17,950 --> 00:58:19,779 but also DOCA and the entire Linux 1807 00:58:19,780 --> 00:58:22,329 namespace movement. 1808 00:58:22,330 --> 00:58:24,070 So my concern with 1809 00:58:25,600 --> 00:58:27,759 with the entire namespace 1810 00:58:27,760 --> 00:58:29,919 stuff that's going on in Linux and all 1811 00:58:29,920 --> 00:58:31,269 of the other systems in general is that 1812 00:58:31,270 --> 00:58:33,549 it actually removes transparency a lot 1813 00:58:33,550 --> 00:58:35,799 because, for example, the user ID user 1814 00:58:35,800 --> 00:58:37,239 credential namespace. 1815 00:58:37,240 --> 00:58:38,319 How annoying is that? 1816 00:58:38,320 --> 00:58:40,030 If you run, for example, 1817 00:58:41,380 --> 00:58:43,299 on on one system, you see that the 1818 00:58:43,300 --> 00:58:45,459 process is running as user 1000 and 1819 00:58:45,460 --> 00:58:47,589 then you just run inside 1820 00:58:47,590 --> 00:58:48,969 of that container or that single 1821 00:58:48,970 --> 00:58:50,559 namespace itself. And it turns out to be 1822 00:58:50,560 --> 00:58:51,909 one million and three. 1823 00:58:51,910 --> 00:58:53,499 It really removes transparency. 1824 00:58:53,500 --> 00:58:55,659 Also, the worst thing that you could even 1825 00:58:55,660 --> 00:58:57,789 come up with is pitting a bit 1826 00:58:57,790 --> 00:58:59,379 namespace virtualization, which is a 1827 00:58:59,380 --> 00:59:01,179 minefield not even needed, if you think 1828 00:59:01,180 --> 00:59:02,859 about it a bit more, because then the 1829 00:59:02,860 --> 00:59:05,139 problem becomes that like 75 1830 00:59:05,140 --> 00:59:07,299 in one environment is not 75 1831 00:59:07,300 --> 00:59:09,549 and another one. And it really 1832 00:59:09,550 --> 00:59:11,589 puts the Chernow's systems administrators 1833 00:59:11,590 --> 00:59:13,659 in might be a necessary reason why 1834 00:59:13,660 --> 00:59:16,299 this system tries to solve it by actually 1835 00:59:16,300 --> 00:59:18,369 cutting off excess fat instead of adding 1836 00:59:18,370 --> 00:59:20,529 more shrink wrap around it to sort of 1837 00:59:20,530 --> 00:59:22,059 make all the existing staff work. 1838 00:59:24,070 --> 00:59:26,529 There's this overly strong mindset 1839 00:59:26,530 --> 00:59:28,749 that for some reason there is no single 1840 00:59:28,750 --> 00:59:31,209 way we can ever change any applications 1841 00:59:31,210 --> 00:59:32,379 and userspace. 1842 00:59:32,380 --> 00:59:34,230 And I think that's a true shame. 1843 00:59:35,440 --> 00:59:37,479 I think, you know, times are changing. 1844 00:59:37,480 --> 00:59:38,799 Unix is already, what? 1845 00:59:38,800 --> 00:59:39,909 Forty years old? 1846 00:59:39,910 --> 00:59:41,799 Forty five years old by now. 1847 00:59:41,800 --> 00:59:43,569 Why can't it change? 1848 00:59:43,570 --> 00:59:45,219 That's that's really what I'm sort of 1849 00:59:45,220 --> 00:59:47,059 trying to experiment with here. 1850 00:59:47,060 --> 00:59:48,669 But but it's a really good market. 1851 00:59:48,670 --> 00:59:49,749 It's actually changing. 1852 00:59:49,750 --> 00:59:51,939 So if you put all 1853 00:59:51,940 --> 00:59:53,979 these things into a System D and you only 1854 00:59:53,980 --> 00:59:56,109 need to configure your system 1855 00:59:56,110 --> 00:59:58,329 properly and every rippin goes away 1856 00:59:58,330 --> 01:00:00,429 and then yes, most 1857 01:00:00,430 --> 01:00:02,529 people don't like System D, but yeah. 1858 01:00:02,530 --> 01:00:03,799 Yeah exactly. 1859 01:00:03,800 --> 01:00:04,629 Yeah. 1860 01:00:04,630 --> 01:00:06,549 Yeah. But I mean it's a it's a different 1861 01:00:06,550 --> 01:00:08,439 solution to, to, to solving a similar 1862 01:00:08,440 --> 01:00:10,209 problem. It's either by adding more 1863 01:00:10,210 --> 01:00:11,739 shrink wrapping around it in the kernel, 1864 01:00:11,740 --> 01:00:13,509 just, you know, adding more and more 1865 01:00:13,510 --> 01:00:15,069 virtualization or namespace 1866 01:00:15,070 --> 01:00:16,539 virtualization features in the kernel to 1867 01:00:16,540 --> 01:00:18,909 work around a problem or just 1868 01:00:18,910 --> 01:00:20,409 saying like we're going to remove stuff 1869 01:00:20,410 --> 01:00:21,699 and use the space that actually contradicts 1870 01:00:21,700 --> 01:00:22,299 with this model. 1871 01:00:22,300 --> 01:00:24,879 So it's two different mindsets. 1872 01:00:24,880 --> 01:00:25,779 Yeah. 1873 01:00:25,780 --> 01:00:27,909 We have time for one very brief question 1874 01:00:27,910 --> 01:00:29,380 from the front right microphone. 1875 01:00:31,330 --> 01:00:33,429 What does this mean for for scripting 1876 01:00:33,430 --> 01:00:34,329 languages in the shell? 1877 01:00:34,330 --> 01:00:36,249 Like if I if I work up a quick shell 1878 01:00:36,250 --> 01:00:37,899 script for automating something in the 1879 01:00:37,900 --> 01:00:40,029 file system, do I need to fiddle with the 1880 01:00:40,030 --> 01:00:42,009 capabilities to get it right or do I just 1881 01:00:42,010 --> 01:00:43,689 run it all powerful and lose the 1882 01:00:43,690 --> 01:00:44,559 advantages? 1883 01:00:44,560 --> 01:00:45,560 So 1884 01:00:47,410 --> 01:00:50,049 the unique shell is something that 1885 01:00:50,050 --> 01:00:51,489 is really something that's sort of 1886 01:00:51,490 --> 01:00:53,379 orthogonal to what I'm developing over 1887 01:00:53,380 --> 01:00:55,809 here. And I'd be amazed if 1888 01:00:55,810 --> 01:00:57,909 you ever get to the point where you 1889 01:00:57,910 --> 01:01:00,429 would just have a shell real like a born 1890 01:01:00,430 --> 01:01:02,409 like shell, a POSIX like shell, where you 1891 01:01:02,410 --> 01:01:04,719 can type in stuff that actually interacts 1892 01:01:04,720 --> 01:01:06,009 with cloud API programs. 1893 01:01:06,010 --> 01:01:08,109 Well, for 1894 01:01:08,110 --> 01:01:09,579 scripting languages, I think it's 1895 01:01:09,580 --> 01:01:11,079 actually different. 1896 01:01:11,080 --> 01:01:13,299 I mean, I'm 1897 01:01:13,300 --> 01:01:15,459 working towards having Python ported over 1898 01:01:15,460 --> 01:01:16,629 to this and then you actually have a 1899 01:01:16,630 --> 01:01:18,339 Python interpreter where you can just run 1900 01:01:18,340 --> 01:01:20,199 all your standard Python scripts in there 1901 01:01:20,200 --> 01:01:21,939 as long as they don't try to open 1902 01:01:21,940 --> 01:01:23,469 arbitrary files on disk. 1903 01:01:23,470 --> 01:01:25,479 And Python actually already has nice 1904 01:01:25,480 --> 01:01:27,099 interfaces for dealing with directory 1905 01:01:27,100 --> 01:01:28,569 file descriptors, for example, in the 1906 01:01:28,570 --> 01:01:29,799 latest versions of Python. 1907 01:01:29,800 --> 01:01:31,489 That is so, um, 1908 01:01:32,530 --> 01:01:34,659 it will break a lot of stuff. 1909 01:01:34,660 --> 01:01:36,759 I'm and that's why I'm saying it's 1910 01:01:36,760 --> 01:01:38,859 going to be a symbiosis and not like a 1911 01:01:38,860 --> 01:01:41,229 simulation. It's really two separate 1912 01:01:41,230 --> 01:01:43,159 environments and. 1913 01:01:43,160 --> 01:01:44,239 We'll see where it goes. 1914 01:01:45,240 --> 01:01:47,239 OK, thank you. Thank you very much, Ed 1915 01:01:47,240 --> 01:01:48,240 Colton.