From f95e8d90fe7c6216cb7885c869fbc5b7272d91eb Mon Sep 17 00:00:00 2001 From: Tony Garnock-Jones Date: Fri, 21 Oct 2022 15:41:20 +0200 Subject: [PATCH] More system layer stuff --- src/synit-as-system-layer.md | 52 +++++++ src/system-layer.md | 287 +++++++++++++++++++++-------------- 2 files changed, 225 insertions(+), 114 deletions(-) diff --git a/src/synit-as-system-layer.md b/src/synit-as-system-layer.md index 335662b..e6f37ba 100644 --- a/src/synit-as-system-layer.md +++ b/src/synit-as-system-layer.md @@ -12,3 +12,55 @@ at the correct level to effectively capture the concepts intrinsic to a system layer. - Protocols capturing a synthesis of system layer behaviours, based on the analysis + + + +The theory of object +capabilities (“ocaps”), exemplified in languages such as E and +programming models such as Actors, offers a fine-grained approach that +can be made to scale further than a single machine. However, ocaps +only control access to shared programs. Access controls for shared +data are left implicit. In addition, ideas of location and system +boundary are left implicit in ocap systems. + +I will adapt ocaps to syndicated actors. Because the Syndicated Actor model includes a +first-class notion of shared data as well as a layered conception of locations and location +boundaries, syndicated capabilities will reflect these ideas directly. I will generalize the +Syndicated Actor model’s existing notions of place, connecting capabilities not to individual +actors but to individual places and the data held therein. I will draw on existing ocap +literature, including in particular the recent notion of Macaroons ([Birgisson et al 2014][]) +and older ideas from SPKI/SDSI ([Ylonen et al 1999][]; [Ellison 1999][]). + + +**Q. How do you feel dataspaces would most enhance privacy or trust?** + +Capability technology offers strong, flexible control over access to any given dataspace +without getting lost in the weeds of identity management: identity is an application-local, +application-private concern. + +Dataspaces default to being closed, "invite-only" networks, meaning casual observation of +activity in a dataspace is not possible. But the necessary extension of the capability model to +handle the data-sharing aspects of dataspaces gives benefit in terms of privacy and trust that +goes beyond the already considerable benefits a traditional capability model offers. + +Traditional capabilities directly control access to behavioural objects, and only indirectly +control access to data held within such objects. Syndicated capabilities, by contrast, directly +control access to shared data held within a space - changes to which may trigger activity in +"objects" participating in the dataspace. + +In other words, traditional capabilities encode data access controls in terms of object access +controls; syndicated capabilities, vice versa. + +This ability to directly express access to shared data gives system designers a powerful tool +for thinking about permitted information flows, including questions of privacy. Furthermore, +*attenuating* the authority of syndicated capabilities before passing them on to some other +principal allows for strong partitioning of access within a dataspace, offering fine-grained, +local, compositional decisions about access to shared data. Finally, it becomes possible to +expose capabilities to end-users (roughly analogous to URLs), putting that power in their hands +also. + +I should also mention that dataspaces can scale from managing activity within a single OS +process up to coordinating activity between machines around the world. A distributed dataspace +could be an excellent foundation for collaborative applications, where privacy concerns come to +the forefront. In effect, a dataspace can become a richly-structured "VPN", containing +application-specific shared data and with application- or schema-specific access controls. diff --git a/src/system-layer.md b/src/system-layer.md index 4f7cf25..5f6c7ea 100644 --- a/src/system-layer.md +++ b/src/system-layer.md @@ -9,7 +9,7 @@ importance lies in its role as the technical foundation for many qualities[^qual to system security, resilience, connectivity, maintainability and usability. In the Linux world, existing system layer realizations cross-cut many, many projects: -NetworkManager, GNOME, DBus, systemd, OpenRC, apt, apk, and so on. Each project has its own +NetworkManager, GNOME, D-Bus, systemd, OpenRC, apt, apk, and so on. Each project has its own role in the overall system layer, and none takes a strong stance on the overall architecture that results from their combination. However, there are a group of basic concepts involved in a system layer that transcend individual subprojects, relating to issues of IPC, discovery, and @@ -124,9 +124,9 @@ These tasks can be broken down into smaller, but still general, pieces: Concrete examples include: - starting services in response to statically-configured runlevels (OpenRC, systemd, SysV init, etc.) - - starting dependencies before dependent services (OpenRC, systemd, SysV init, etc.) + - starting dependencies before dependent services (OpenRC, systemd, SysV init, etc.), including readiness-detection and -signalling - restarting terminated or failed services in a supervision hierarchy (daemontools, s6, etc.; Erlang/OTP) - - starting services by service name on demand (DBus, etc.) + - starting services by service name on demand (D-Bus, etc.) - starting services by socket activation (systemd, etc.) - virtual-machine and container lifecycles, including supervision and restart of containers (docker, docker-compose, etc.) - reacting to hotplugging of a device by installing a driver or starting a program (udevd, etc.) @@ -141,14 +141,22 @@ distributions](https://skarnet.com/projects/service-manager.html). ## Higher-level perspectives on and control over system state and resources -An essential system layer task is to give users and applications higher-level perspectives on -system state, resource availability and resource consumption than those offered by the kernel. +An essential system layer task is to give users and applications **higher-level perspectives** +on system state, resource availability and resource consumption than those offered by the +kernel. This has two parts: refining low-level information about system state into higher-level +knowledge, and reflecting user (or application) preferences expressed in terms of the +higher-level perspective back into concrete actions to perform at the lower level. -For example, the kernel's [`NETLINK_ROUTE`](https://en.wikipedia.org/wiki/Netlink) sockets -allow processes to observe changes in network interface and routing configuration, but -applications often do not need the fine detail on offer: instead, they need higher-level -knowledge such as "a usable default route for IPv4 exists", or "IPv4 connectivity is available, -but metered". +As an example of the first, the kernel's +[`NETLINK_ROUTE`](https://en.wikipedia.org/wiki/Netlink) sockets allow processes to observe +changes in network interface and routing configuration, but applications often do not need the +fine detail on offer: instead, they need higher-level knowledge such as "a usable default route +for IPv4 exists", or "IPv4 connectivity is available, but metered". + +As an example of the second, NetworkManager allows users to set policy for wifi connection +establishment in terms of a priority ordering over SSIDs and conditions for when and whether to +use a particular network. NetworkManager's job is to translate this into a sequence of +low-level wifi scans, associations and disconnections. Breaking this task down into smaller pieces yields: @@ -156,6 +164,8 @@ Breaking this task down into smaller pieces yields: - ability to either poll for or subscribe to changes in such state - ability to compute relevant higher-level perspectives on the state - a medium for communicating such changes to users and applications + - a medium for retrieving preferences and actions from users and applications + - ability to perform actions on low-level system resources Concrete examples include: @@ -163,7 +173,7 @@ Concrete examples include: - use of `NETLINK_KOBJECT_UEVENT` by udev to configure and expose hotplugged devices to userland - interrogation of disk devices and partition tables to provide views on and control over available filesystems (gnome-disks, etc.) - interrogation of audio devices and audio routing options to provide high-level views and control over audio setup (pipewire, pulseaudio, etc.), e.g. volume level display and volume controls, mute, select input/output channel, play/pause, skip, rewind etc. - - high-level perspectives on devices such as displays, printers, mice, keyboards, touchpads, accelerometers, proximity sensors, temperature monitors and so on (GNOME, XFCE4, KDE, cups, etc.), communicated via DBus and friends + - high-level perspectives on devices such as displays, printers, mice, keyboards, touchpads, accelerometers, proximity sensors, temperature monitors and so on (GNOME, XFCE4, KDE, cups, etc.), communicated via D-Bus and friends - system configuration databases (`/etc`, Windows' Registry, GNOME configuration databases) - location services mapping from low-level GPS and wifi information to medium-level concrete location coordinates to high-level "you are at home", "you are in the office"-style knowledge about location - telephony services exposing high-level call management interfaces backed by low-level modem operations @@ -180,147 +190,187 @@ system services are analogous parts of the system layer. ## Access control mechanisms and policies, security, and privacy - - offer access control mechanisms and enforce access control policies - - offer a coherent, system-wide approach to security and privacy +An inescapable concern when composing software across trust domains is **access control**. +System layers provide mechanisms for controlling access to software resources and data, allow +users and applications to specify access control policies, and enforce those policies on their +behalf. - - *access control* - - resource allocation services - - ACL-based access control for system services and DBus objects +Given the increasingly blurry lines between local and cloud-based personal computing, the scope +of access controls can be broad, including confidentiality and integrity protections for user +data and careful control over user privacy. -### Security and privacy +Multiple trust domains appear even in a single-user personal computing system: the kernel is +its own trust domain; its daemon representatives within the system layer are at least one +other; the user is a trust domain, and its system-layer representatives another; and each +application is a trust domain, particularly when it is a third-party application acting on +behalf of a user, perhaps bringing cloud services into the picture. Moving from a single- to a +multiple-user system then adds only minor complexity. -Existing system layers rely on single-machine approaches to security -and securability that do not scale well: for example, Unix ACLs and -user- and group-ID-based permissions. The theory of object -capabilities (“ocaps”), exemplified in languages such as E and -programming models such as Actors, offers a fine-grained approach that -can be made to scale further than a single machine. However, ocaps -only control access to shared programs. Access controls for shared -data are left implicit. In addition, ideas of location and system -boundary are left implicit in ocap systems. +Existing system layer realizations, at least within the Linux world, tend to address access +control, security and particularly privacy at a relatively primitive level, relying on +single-machine approaches to security and securability that do not scale well: for example, +Unix [ACLs](https://en.wikipedia.org/wiki/Access-control_list) and user- and group-ID-based +permissions. -I will adapt ocaps to syndicated actors. Because the Syndicated Actor model includes a -first-class notion of shared data as well as a layered conception of locations and location -boundaries, syndicated capabilities will reflect these ideas directly. I will generalize the -Syndicated Actor model’s existing notions of place, connecting capabilities not to individual -actors but to individual places and the data held therein. I will draw on existing ocap -literature, including in particular the recent notion of Macaroons ([Birgisson et al 2014][]) -and older ideas from SPKI/SDSI ([Ylonen et al 1999][]; [Ellison 1999][]). + - Debian, Alpine, and other Unix-like Linux distributions offer little or no access controls + other than those provided by the kernel -**Q. How do you feel dataspaces would most enhance privacy or trust?** + - Android uses the kernel user ID mechanism in a different way, giving an effective + improvement in separation between trust domains when compared to traditional Unix approaches -Capability technology offers strong, flexible control over access to any given dataspace -without getting lost in the weeds of identity management: identity is an application-local, -application-private concern. - -Dataspaces default to being closed, "invite-only" networks, meaning casual observation of -activity in a dataspace is not possible. But the necessary extension of the capability model to -handle the data-sharing aspects of dataspaces gives benefit in terms of privacy and trust that -goes beyond the already considerable benefits a traditional capability model offers. - -Traditional capabilities directly control access to behavioural objects, and only indirectly -control access to data held within such objects. Syndicated capabilities, by contrast, directly -control access to shared data held within a space - changes to which may trigger activity in -"objects" participating in the dataspace. - -In other words, traditional capabilities encode data access controls in terms of object access -controls; syndicated capabilities, vice versa. - -This ability to directly express access to shared data gives system designers a powerful tool -for thinking about permitted information flows, including questions of privacy. Furthermore, -*attenuating* the authority of syndicated capabilities before passing them on to some other -principal allows for strong partitioning of access within a dataspace, offering fine-grained, -local, compositional decisions about access to shared data. Finally, it becomes possible to -expose capabilities to end-users (roughly analogous to URLs), putting that power in their hands -also. - -I should also mention that dataspaces can scale from managing activity within a single OS -process up to coordinating activity between machines around the world. A distributed dataspace -could be an excellent foundation for collaborative applications, where privacy concerns come to -the forefront. In effect, a dataspace can become a richly-structured "VPN", containing -application-specific shared data and with application- or schema-specific access controls. + - D-Bus authenticates each connection separately, usually mapping principal identities onto + Unix user IDs; within the scope of a connection, it uses ACLs to make authorization + decisions + - Some isolation among trust domains can be achieved with careful use of [kernel + namespaces](https://en.wikipedia.org/wiki/Linux_namespaces); however, namespaces are not + fine-grained and are awkward to use for privacy-protection purposes. They see use primarily + for resource isolation in containerization systems. ## Inter-process communication and networking - - offer inter-process communication media +> Networking is interprocess communication. +> *—Robert Metcalfe, 1972, quoted in [Day 2008][]* - - *inter-process communication* - - DBus as a program-to-program communication bus - - email for use by system services +A key part of an operating system is the selection of communications media it offers its +applications. The kernel itself offers a plethora of communication channels, from the file +system itself through SysV IPC, shared memory, and pipes up to sockets in multiple flavours. -X11 for IPC +System layers need richer facilities in order to handle the reactivity, publish-subscribe, +name-discovery and -management and access control needs previously discussed. In addition, the +concept of an "address" within a system layer is often more complex than the low-level endpoint +addresses on offer by the kernel: for example, D-Bus object names, email addresses and aliases, +and Docker container names do not fit easily into kernel constructs, and this applies double +for the addresses of fine-grained resources (e.g. single objects) within a process. + + - Traditional Unix-like system layers configure *email* for use by system services, primarily + for system-to-user communication but also in principle for program-to-program communication. + + - D-Bus is a coarse-grained, ACL-based message bus with an ad-hoc object model and + publish-subscribe mechanism. It has been used as the foundation for a lot of system layer + software such as the components in the GNOME desktop environment and the building-blocks of + NetworkManager and similar services. + + - X11 offers multiple methods by which clients can communicate with each other. Primary + applications include shared clipboard management and window management, but the selection + and property change notification mechanisms are general-purpose and could in principle form + an interesting substrate for organising software components. + + - Android IPC is (if I understand correctly!) primarily based around + [binder](https://elinux.org/Android_Binder) and layers a number of communication + "personalities" on top of it (such as + [AIDL](https://developer.android.com/guide/components/aidl), + [Broadcasts](https://developer.android.com/guide/components/broadcasts), and + [Messenger](https://developer.android.com/reference/android/os/Messenger)s). Binder is + apparently ([1](https://elinux.org/Android_Binder), [2](https://lkml.org/lkml/2009/6/25/3), + [3](https://lwn.net/Articles/466304/)) a (mostly) object-capability ("ocap") system, with + fine-grained object passing, failure-signalling (a "link to death" facility, much like + Erlang's [links and + monitors](https://www.erlang.org/docs/22/reference_manual/processes.html#links)), and + distributed garbage-collection[^binder-vs-syndicate] that is extremely widely used in + Android. + + From a [2009 email from Dianne Hackborne](https://lkml.org/lkml/2009/6/25/3): + For a rough idea of the scope of the binder's use in Android, here is a list of the basic + system services that are implemented on top of it: package manager, telephony manager, app + widgets, audio services, search manager, location manager, notification manager, + accessibility manager, connectivity manager, wifi manager, input method manager, clipboard, + status bar, window manager, sensor service, alarm manager, content service, activity + manager, power manager, surface compositor. ## Name-binding, name-resolution, and namespaces - - provide name-binding and name resolution services - -udev - /dev namespace - - - *naming services* - - publishing names for intra-machine services on this system - - publishing names for LAN services on this system - - resolving names of intra-machine services on this system - - resolving names of services on other systems[^libc-resolver] - +Many of the services offered by a system layer involve management and querying of mappings +between high-level *names* and (zero or more) lower-level *addresses* ([Day 2008][]). These +appear in many different guises, from the directories in the file system, to DNS names (mDNS +services like [avahi](https://www.avahi.org/); the libc resolver; services like dnsmasq), to +device names (managed by udev), to object names (DBus), to service names, to preconfigured +connection settings (NetworkManager), to user and group names and so on. Namespace management +is a core feature of a system layer. ## Job queueing and job scheduling - - provide job-queueing and -scheduling services, including calendar-like and time-based scheduling +System layers frequently provide job-queueing and -scheduling services, including calendar-like +and time-based scheduling. As a corollary, they also provide job- and schedule-management +interfaces. -cron -at -systemd timers + - Traditional Unix has `cron` and `at` for job scheduling. -cups, lpd + - Android has system [alarm services](https://developer.android.com/reference/android/app/AlarmManager). -mail queue management? + - systemd has [timers](https://www.freedesktop.org/software/systemd/man/systemd.timer.html) as + a replacement for `cron`. + + - systemd also has a [job + engine](https://www.freedesktop.org/software/systemd/man/systemd-run.html) (see also + [here](https://www.freedesktop.org/software/systemd/man/systemctl.html#Job%20Commands) and + [here](https://bl33pbl0p.github.io/systemd.html)) for decoupling work in space and time. + + - print queues like `lpd` and `cups` are job management engines at heart + + - you can even see the mail queue as a kind of job queue (and if you squint *very* hard, you + can see all the intermediate buffers in a networking or IPC system as job queues; cf [Day + 2008][]). ## User interface - - provide user interface facilities +The user interface is a classic example of a system facility that cross-cuts individual +applications and tasks. A system layer must provide some kind of user interface service to +applications (and to its own system services). -(TO APPLICATIONS but I guess also for the system layer itself) + - At a minimum, Unix-like kernels offer `tty`s. Access to a system via `ssh` is a natural next + step. - - provide system-wide "cut-and-paste" services for user-controlled IPC + - X11 is the traditional Unix user interface, with its own IPC protocol and ad-hoc object + model; wayland is a recent entrant into a similar space, also with its own IPC protocol and + ad-hoc object model. Android offers [SurfaceFlinger and + WindowManager](https://source.android.com/docs/core/graphics/surfaceflinger-windowmanager) + along with a large library of user interface widgets; the underlying IPC is presumably + binder ([see above](#binder)). -email for talking to users -notifications - system tray + - In Smalltalk-80-derived systems (like [squeak](https://squeak.org/)), the user interface is + tightly integrated with the multiprocessing and IPC facilities (such as they are). Squeak + also offers simple, quick-and-dirty "alert" and "prompt" APIs to applications, similar to + the + [`alert`](https://developer.mozilla.org/en-US/docs/Web/API/Window/alert)/[`prompt`](https://developer.mozilla.org/en-US/docs/Web/API/Window/prompt)/[`confirm`](https://developer.mozilla.org/en-US/docs/Web/API/Window/confirm) + functions included in web browsers. - - ui facilities - - the thing that asks for user input during apt configuration - - the alert/prompt boxes in a web browser (?) - - notifications - - system tray, applets + - Many, but not all, system layers provide a system-wide "cut and paste" service as part of + their user interface, for *user-controlled* IPC. X11 applications have a clipboard + convention; Mac OS, Windows, Android etc. have a standard clipboard. -## System configuration and user preferences + - System-level *email* can be seen as a form of user interface for reaching users (system + administrators). - - provide system configuration and user preference databases + - Many desktop environments include *notifications* and some form of *system tray* giving + quick reference to high-level perspectives on system status as previously discussed. - - system configuration database - - system settings manager + - Some system-layer administration tasks require user interface: for example, user input + during `apt` package configuration. ## Software management - - support software package installation, upgrade, and removal - -cc -apt -apk +System management involves upgrade of system code and installation, management and removal of +application code. Android has a solid story around software management. Linux distributions +tend to have package management tools (e.g. `apt`, `apk`, `yum` etc.). Stretching a little +further, one might include the system programming language and its development environment as +part of the software management portion of a system layer: for example, many Unix-like systems +include `cc`, and Smalltalk systems make the system programming language (Smalltalk) available +from any text input field. ## State replication and data backup - - offer state replication services - - provide data backup facilities +The notion of state replication appears in many different contexts. For example, user +contact/address databases must often be replicated and accessible across devices. System +configuration data is often shared across servers in a cloud deployment (ansible, puppet). Many +add-on applications like Dropbox, NextCloud, Syncthing etc. add file replication to a system. +Applications like Google Keep, to-do list applications, and other sticky-notes/reminder apps +replicate their databases across machines. Very few system layer realizations offer a coherent +data replication facility, despite its clear cross-application utility. - - state replication services - - contact book, address book - - file replication across machines - - sticky-notes, google keep - - todo list - - - backup facilities - - Time Machine +Relatedly, preserving user data in case of calamity is a core operating system feature. Despite +this, few whole systems offer a coherent data backup facility. Exceptions include Apple's Time +Machine and Google's Android backup support libraries. ## Synthesis, or, Toward a Complete Vision of a System Layer @@ -354,6 +404,8 @@ to be good IPC and state-management and -introspection. | GNOME | | ✓ | ✓ | ✓ | | | | | ✓ | ✓ | | | | Android | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | | | + - ideally, a system layer's security mechanisms would offer a coherent, system-wide approach + to security and privacy. few do so ## References @@ -377,6 +429,10 @@ Klein. Evaluating Software Architectures: Methods and Case Studies. Addison-Wesl [**Corbet 2019**] Corbet, Jonathan. “Systemd as Tragedy.” LWN.Net, January 28, 2019. . +[Day 2008]: #ref:day08 +[**Day 2008**] Day, John. Patterns in Network Architecture: A Return to +Fundamentals. Prentice Hall, 2008. + [Ellison 1999]: #ref:ellison99 [**Ellison 1999**] Ellison, Carl. SPKI Requirements. Request for Comments 2692. RFC Editor, 1999. . @@ -413,3 +469,6 @@ Comments 2693. RFC Editor, 1999. . [^libc-resolver]: The resolver built in to libc plays the major part in this; but things like dnsmasq play a role too, especially when combined with virtual machines running within a host. + +[^binder-vs-syndicate]: Looking at binder, I see *strong* similarities with the [Syndicated + Actor Model](syndicated-actor-model.md) and its [protocol](protocol.md)!