https://homeostasis.scs.carleton.ca/wiki/index.php?action=history&feed=atom&title=Operating_Systems_2019W_Lecture_21 2026-04-05T18:28:39Z Revision history for this page on the wiki MediaWiki 1.42.1 https://homeostasis.scs.carleton.ca/wiki/index.php?title=Operating_Systems_2019W_Lecture_21&diff=22313&oldid=prev 2019-04-01T23:06:58Z

<p>Created page with &quot;==Video== The video from the lecture given on April 1, 2019 [https://homeostasis.scs.carleton.ca/~soma/os-2019w/lectures/comp3000-2019w-lec21-20190401.m4v is now available]....&quot;</p> <p><b>New page</b></p><div>==Video==<br /> <br /> The video from the lecture given on April 1, 2019 [https://homeostasis.scs.carleton.ca/~soma/os-2019w/lectures/comp3000-2019w-lec21-20190401.m4v is now available].<br /> <br /> ==Notes==<br /> <br /> &lt;pre&gt;<br /> Lecture 21<br /> ----------<br /> <br /> A4 Quiz coming out Sunday night, substitue for A4 submission<br /> - you can still submit A4, but it won&#039;t be graded unless you ask for it to because you don&#039;t think your answers to the multiple choice questions matches your understanding of the material. Likely the grading will be in an in-person meeting.<br /> <br /> Fine-grained access control<br /> ---------------------------<br /> (and alternative ways of doing access control)<br /> <br /> When you run with privileges, drop them as soon as you can<br /> <br /> If you&#039;re in a setuid root context, you can drop privileges by<br /> running seteuid(), change it to process&#039;s real UID<br /> <br /> assume uid=1000, euid=0<br /> if you run seteuid(1000), then uid=1000, euid=1000<br /> <br /> but<br /> <br /> you can still run seteuid(0) after doing this!<br /> - so only worth doing if you know attacker can&#039;t take control<br /> of code (e.g., no code injection vulnerabilities)<br /> <br /> You can make the euid change permanent if you then do an execve<br /> <br /> But still, this is very coarse - you either can do everything or you can<br /> do almost nothing<br /> <br /> <br /> Ideally you&#039;d like to split up the powers of root into subsets<br /> - so you&#039;d only keep the privileges you need<br /> <br /> Well, what can root do?<br /> - access any file<br /> - mount/unmount filesystems<br /> - allocate low-numbered ports (&lt;1024)<br /> http 80<br /> https 443<br /> ssh 22<br /> smtp 25<br /> auth smtp 465<br /> - configure networks<br /> - access block devices<br /> - set the time<br /> ...<br /> <br /> Linux kernel capabilities allow you to control whether a process can or<br /> cannot do different kinds of privileged operations<br /> - normally a process starts as roots and then drops capabilities it doesn&#039;t need<br /> - but you can be &quot;setuid&quot; for capabilities using extended attributes<br /> (on some filesystems)<br /> <br /> <br /> Why dow we want fine-grained access control? Is it really better?<br /> - well, it limits damage when an attacker gets control<br /> - but it makes the jobs of developers, users, and admins harder<br /> <br /> SELinux allows for very fine-grained access control (and more)<br /> - but mostly people want to disable it, because they don&#039;t understand it<br /> <br /> Android permissions<br /> - fine grained in a mostly useless way<br /> <br /> Nowadays we do more sandboxing rather than fine-grained access control<br /> - default deny, limited flexibility rather than arbitrary flexibility<br /> <br /> Discretionary versus mandatory access control (DAC vs MAC)<br /> - discretionary: can change at runtime<br /> - mandatory: *cannot* change at runtime, must reboot into special mode<br /> <br /> MAC limits the power of root<br /> - root can&#039;t change the policies at runtime<br /> - useful at times but can be very very painful to use, thus<br /> most common question about systems like SELinux is how to disable it<br /> <br /> Sandboxing<br /> - not a technology, more a hope or goal<br /> <br /> a sandbox is an environment for running programs in which the program stays isolated from the outside world (except for &quot;safe&quot; connections)<br /> - so it is safe to run untrusted code inside of a sandbox<br /> <br /> Since more and more code isn&#039;t trusted, sandoxes show up everywhere<br /> <br /> A process itself is a kind of sandbox - but a very very leaky one<br /> <br /> processes have lots of shared state<br /> - filesystem<br /> - process list/signals<br /> - IPC of all kinds<br /> <br /> How do you &quot;sandbox&quot; a program?<br /> A add restrictions to processes<br /> B add restrictions to the OS<br /> C implement a &quot;virtual machine&quot; of some kind, run it in there<br /> (using a language that the native machine can&#039;t run directly)<br /> <br /> A is containers &lt;-- hacks on the OS<br /> B is hardware virtual machines (VMWare, kvm, etc) &lt;-- isolate the OS<br /> C is Java and JavaScript<br /> <br /> C can provide the strongest guarantees but has considerable complexity<br /> B is very heavyweight (new kernel per isolated instance)<br /> A is fashionable and not so good<br /> <br /> Containers allow a kernel to run multiple, separate userlands<br /> - potentially each with its own set of users including root and<br /> its own filesystem structure<br /> <br /> WebAssembly<br /> <br /> First, there was the JavaScript sandbox<br /> - limited capabilities (no background processing, no filesystem access,<br /> very limited network access)<br /> - then came AJAX (or just AJ now), so JavaScript became more powerful<br /> - got full apps in JavaScript, so runtimes had to get faster<br /> - V8 was so good, was moved to the server (node.js)<br /> <br /> Javascript is everywhere, is fast, can do sandboxing, but not everyone likes it<br /> <br /> Emscripten came along - allow you to compile arbitrary languages to Javascript<br /> <br /> Mozilla came up with asm.js - subset of JS as a target for Emscripten<br /> <br /> Google came up with NaCl - native client, subset of x86 for browsers<br /> <br /> asm.js + NaCL =&gt; WebAssembly<br /> &lt;/pre&gt;</div>

Soma