They're still attacks.
Curious: how do you implement MM filters, such as paging and compressed memory? What about file system filters such as unionfs?
There are a lot of interesting things you can do in modern OSes. Those capabilities also imply code running in dangerous places, like between the FS and the user, or on the virtual memory manager.
On Fri, Sep 14, 2018, 10:23 PM Andrew Warkentin andreww591@gmail.com wrote:
On 9/14/18, John john.r.moser@gmail.com wrote:
Those processes with limited hardware access are able to do funny thing.
The process that manages virtual memory, for example, can get into the memory space of any process running on the system. It crosses all
security
boundaries.
Under UX/RT it will be impossible to load code into either the process server or the kernel (which will be the most security-critical components in the system), and both will be based on safer code (the kernel will be seL4, and the process server will be written in Rust), so the attack surface will be very small.
If you load a rogue VFS driver, it can take over all file system access, injecting code into software and crossing all security boundaries.
Not on UX/RT. Filesystem servers will not be able to control the entire VFS. They will only have control over filesystems they export. In fact, they will not be able to access the VFS at all as anything other than a client until another process mounts their filesystems (to act as a filesystem server, a process will request a "port" from a special filesystem built into the root server, and then some other process, usually the mount command, will send a request to the root server to mount the port on a directory, analogous to mounting a block device in a conventional Unix).
So imagine if you loaded a malicious network card driver into L4. It's running Ring-3, it's passing IPC messages to the L4 kernel and to the TCP stack, it has its own memory space, and it's tampering with your
connection
and sending copies of bank data to a command and control server in
Russia.
Yes, but the malware can't make itself persistent unless it was installed some other way, since the network stack won't have privileges to install software. Under UX/RT, only the package manager or a shell session with the proper administrative role will be allowed to install software. The package manager will have a "locked open" verification scheme based on reproducible builds, where multiple mirrors controlled by different organizations in different countries will all build the same source from the same commit and sign the package if the binary matches, which will require all changes to be on the record, and replacing a verified package with a non-verified one will fail unless explicitly overridden.
l4-hackers mailing list l4-hackers@os.inf.tu-dresden.de http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers