Soma: Created page with "==Video== Video from the lecture given on April 1, 2020 [https://homeostasis.scs.carleton.ca/~soma/os-2020w/lectures/comp3000-2020w-lec22-20200401.m4v is now available]. ==N..."

2020-04-01T20:36:47Z

Created page with "==Video== Video from the lecture given on April 1, 2020 [https://homeostasis.scs.carleton.ca/~soma/os-2020w/lectures/comp3000-2020w-lec22-20200401.m4v is now available]. ==N..."

New page

==Video==

Video from the lecture given on April 1, 2020 [https://homeostasis.scs.carleton.ca/~soma/os-2020w/lectures/comp3000-2020w-lec22-20200401.m4v is now available].

==Notes==

<pre>
Lecture 22
----------

- scheduling
- start semester review
- answer questions about tutorials 8, 9, and assignment 4
- final exam review session

- multiple choice A4 questions due before lecture on Friday
- will go over them in class

- culearn submissions for A4 multiple choice will open this evening
- just fiddling with cuLearn
- note that answers may be randomized relative to those
on the wiki, so make sure you select the right answers
- there's no time limit, but has to be completed by 2:30 PM Friday

- will also open submissions to short answers for A4
- completely optional, but should be also submitted by class
on Friday as I will distribute solutions to them
- If you mess up on the multiple choice questions but
submit the short answers, we can grade them, but
only on request

- Final exam review session
- April 9th, 2:30 PM if that works for everyone?
- please answer the poll, if too many people can't
make it will consider other times
- will livestream and record as usual, can ask questions in advance
(and of course on discord)
- will go through topics as before for midterm

- Final exam on April 13, 7 PM
- will post on cuLearn at 7 PM
- upload solutions as a text file by 9 PM
- open book, open internet, but NO COLLABORATION
- if you have PMC accommodations, submit after your extra time
(i.e, with 50% more time, submit by 10 PM)

Thoughts related to Zoom
- if you download and run code in Linux, normally this code has full access
as whatever user runs the program
- so if I run a program, it can do everything that I can do as a user
- this is potentially a problem with proprietary software, because
who knows what it could do?

Linux distributions have developed ways to distribute software outside of normal packaging
- big concern: limiting access of third party code
- unlike software coming from the distribution, there's been no
third party review

snap and flatpak are two standards for distributing software for linux systems
in a self-contained way
- allows third party to update code separately from linux distribution
- works accross linux distributions
- key idea: installed software is confined in some way (generally)

snaps are confined in multiple ways
- have their own filesystem, with local resources mounted to specified locations in their filesystem
- can't access files outside of their filesystem by default
- yes, this is a kind of container!

This sort of confinement is standard practice on iOS
- Android has per-app permissions but Android apps aren't as isolated
as iOS apps (but they have gotten much closer in more recent releases
of both systems)

- Microsoft was trying to push similar tech with their app store,
but that hasn't had as much traction due to legacy app concerns
(and protests from existing software developers, companies)

- Apple is trying to make 3rd party apps more confined when installed
through the Mac app store, but they also have push back (but have
been more successful than Microsoft)

Classic desktop environments didn't confine apps, so confinement was really developed for mobile systems and is being retrofitted onto desktops and servers.

If I'm going to install software that isn't part of Ubuntu, I try to do it with a snap if at all possible. (Ubuntu -> snap, Red Hat -> flatpak)

snaps have no performance reduction, except that snaps can take up more disk and RAM
- use their own libraries for portability, can't depend on what comes
with the distribution

the "zoom sending to facebook" thing seems to be them using the Facebook SDK to add "login with facebook" functionality and it phoning home by default
- but when you dig deeper there are a number of other shady things,
like leaving code around after an uninstall so zoom will be auto-installed
when a user attempts to join a zoom call (on MacOS I believe)

snaps are completely optional, the base ubuntu system doesn't use it except for a few popular apps (e.g., chromium)

process-control allows you to control arbitrary processes (not sure the mechanism, but I assume send signals, run ptrace, etc). I think it is just for processes you own, but that is bad enough. (I hope it isn't for all system processes but it may be!)

you can control privileges granted to zoom when in a snap - but you can't if
you install it with a .deb (the default)

It is always safer to run apps in a browser rather than installing them
- installed versions always have more privileges
- code in browsers is carefully isolated (sandboxed)

ubuntu software center installs debs and snaps
- I believe it is curated, FWIW
- confinement only happens with snaps

When we talk about software in Linux distributions, all software isn't equally trusted
- there is always a "main" repository and then extra ones
- you can trust the main one (you have to, have no choice), but
the other repositories, it depends

In ubuntu terms, main is the most trustworthy, while universe, multiverse,
and restricted are less trustworthy (probably okay but only install what you really use).

Then there are snaps (confined mostly, but depends), ppa's (specific repositories for apps, often put together by original developers, e.g. bcc has a ppa, no confinement). There it depends too

Always risks when installing software!

A "jail break" is breaking the app-level confinement on iOS devices. So while it lets you do more, it also fundamentally reduces your security because apps are no longer confined (jailed).
- jail is an old BSD tech for confining applications,
genesis of many ideas around modern containers

This material is not covered in the assignments or tutorials
- so purely optional
- however, if you can't follow what I'm saying you may be missing
certain key concepts from earlier

Browser extensions are essentially web pages with limited confinement
- they have permissions, but they get much more access (by default and
with commonly asked for permissions) than regular pages
- it is normal for a browser extension to see every URL you type in,
- it is also normal for extensions to be able to mess with the contents
of any page and to access and change arbitrary files
(regular web pages can't do this!)
- so again only install browser extensions if you really need them,
and then consider ways to restrict them (limit permissions, use
multiple browser profiles)

Containers are a browser-level way to confine information
- limit scope of cookies, other saved data
- can limit tracking and other attacks

Chrome has profiles (different "users") apparently, but I don't think they
have a container equivalent

Note general theme: put things in boxes to improve security!
- too many kinds of boxes

The actual memory allocators in the Linux kernel are outside the scope
of this class
- tutorial 8 shows a bit of what is going on under the hood, but
that is just a start
- is not in the assignments and thus won't be on the final

#define headers

remeber in C we have the C compiler and the C pre-processor
- everything starting with # is a pre-processor directive
- can define and run macros that change C code in lots of ways
- people have used it to turn C into almost a completely
different language
- pre-processor directives can be added at compile time with -D
- equivalent to #define in the source code
- allows a way to change how code is compiled without
changing the code itself (just change a #define on the command line
using -D)

When you see a variable starting with __ in C source code, it normally
means it is private in some way
- this isn't part of the API
- this isn't the function or variable you are looking for,
move along!
- (note that C doesn't restrict the scope of functions so need
conventions to say what is internal and what isn't)

Remember system calls are a different thing than function calls
- invoked directly from userspace using a special assembly language instruction
- as a result, when you get into the kernel, system call code isn't
called like a normal C function. We need assembly glue code
- special declaration of system call entry functions takes care of the
glue code. Once we're past it, we can just call normal C functions

Don't think about weird things like drop_caches for Q1 on A4
</pre>

Operating Systems 2020W Lecture 22 - Revision history

Soma: Created page with "==Video== Video from the lecture given on April 1, 2020 [https://homeostasis.scs.carleton.ca/~soma/os-2020w/lectures/comp3000-2020w-lec22-20200401.m4v is now available]. ==N..."