Security and privilege levels

Having been playing around with RO on the Pi over the last day or so, I’ve remembered what a nice responsive system it is, particularly for those of us who are techies.

Anyway, a few thoughts for features I’d like to see added:

Security. At present RO has none. Let’s introduce the concept of user IDs into the OS, and ownership of tasks/files/directories.

Have a single login post-boot, which can either authenticate to a local user database or to some form of login server (using a plug-in style method). This could be Kerberos, NFS, LanMan or even AUN. (OmniClient will already authenticate to a LanMan domain so this shouldn’t be a problem.)

Have different privilege levels. Probably nothing so complicated as the Windows model, but the *nix model would work, ie all users except “root” are unprivileged, you type one command followed by the root password to elevate privileges. (Perhaps we could call the superuser “administrator” or “admin” rather than “root”, it’s a bit more friendly.)

Introduce ACLs into the file system so you can retain ownership of a file or directory but grant read/write/modify (as appropriate) access to another user. The superuser can obviously override all ACLs.

A user can only Alt-Break their own processes, not those started by the superuser. I’m sure the top 8 bits of the task handle could be used for the user ID.

A new SWI, OS_Logout (or even UserManager_Logout) that quits all tasks started by that user and returns to the login screen. (Or restarts the computer depending on configuration.)

I’m not suggesting trying to make RO a true multi-user system like Unix (or even newer versions of Windows), but it would be nice to have some form of security at the desktop level.

Rather than applying the security model of another OS, let’s step back a bit. What are you trying to achieve? There are various tools to implement possible security policies, but it’s perhaps better to work out what the security and threat model is going to be before diving into the implementation.

but it’s perhaps better to work out what the security and threat model is going to be before diving into the implementation.

Strikes me as a rather pointless pursuit to “harden” up the OS while the kernel and user modules share SVC mode, and a simple SWI call will give you unfettered access to everything.

The only way this can work is to push modules to SYS mode and run only the kernel (and maybe FileCore) in SVC. That way the kernel can lock out parts of the system as private to itself and attempt to exert some sort of control over who can access what.

That said – take a look at Zap’s ability to rip application workspace (of other applications), not to mention module code and workspace.
RISC OS goes out of its way to make this sort of thing relatively easy. I don’t think we can get a coherent security model without rewriting a lot most of the OS.

Perhaps better to accept that this just isn’t how we roll. ;-)

The only way this can work is to push modules to SYS mode and run only the kernel (and maybe FileCore) in SVC. That way the kernel can lock out parts of the system as private to itself and attempt to exert some sort of control over who can access what.

SYS mode is at the same privilege level as SVC. The only real benefit you’d get from using SYS is protecting the SVC stack from accidental clobbering.

One thought I’ve been having lately is using a Pi as an ultra-thin client, running the UI in the RO desktop. The actual application runs on a big scary unix box, which just sends the windowing primitives (basically the Wimp window data) over a TCP connection and receives all the Wimp events back. (I’m thinking an uber-hack of Brandy Basic or similar might help here.)

The thing with Zap ripping memory – if this were to be implemented, you’d only be able to rip memory from applications running under your own user ID, unless Zap was running under the super user account.

What I like about *nix, and even recent versions of Windows is this. Back before xmas I had to go away for a couple of days, so I created a user account each on the Samba domain for my lodgers. I then logged out of my desktop PC before I went. They were able to log in, check emails, Facebook etc. They couldn’t install any software or change any system settings whatsoever. Of course the F12 boot menu was disabled in the BIOS, the BIOS was passworded, and there was a padlock on the computer’s case so he couldn’t pull the side panel off and move the jumper to reset the CMOS. And the server was locked in a secure location to which he didn’t have the key.

The security worked, I got back to find the computer still working (and several failed login attempts on my account where he was trying to guess my password). He’d pulled every USB connector out of the system, but that’s another story (I think he may have been trying to boot from a USB key to reset the admin password, but of course he couldn’t).

Anyway, back to the original topic. I’m not suggesting we have a full multi-user system like *nix or NT, but I do think having the concept of “privileged users” would be a good thing. Nothing major, I’m thinking kind of like the “priv” flag on Level 4 server, along with an “owner” attribute on the file system. Privileged users can read other people’s files, change critical system settings like the clock, number of disks etc, unprivileged users can only see their own files or files set to “public”, can’t run Configure (the app or the * command), and, depending on the level of restriction, can’t change the screen mode. ¹

¹ No, I’m not mad. Nowadays with TFT monitors you need to run them at their native resolution otherwise they look pretty terrible. So, set the screen mode to the native resolution of the panel, the highest available refresh rate and the maximum colour depth (on this laptop that’s 1368×768, 60Hz, 32bpp) and lock it down at that setting.

One thought I’ve been having lately is using a Pi as an ultra-thin client, running the UI in the RO desktop. The actual application runs on a big scary unix box, which just sends the windowing primitives (basically the Wimp window data) over a TCP connection and receives all the Wimp events back. (I’m thinking an uber-hack of Brandy Basic or similar might help here.)

No idea whether the concept would work usefully, but if you were working with a dual processor¹ system:
Run your core in one processor and the applications in another. A sort of internalised utilisation of the Jaffasoft ActiveApps concept which built on the Impulse concept. Of course in a Pi array, or a compute array, you’d have quite a few cores. Pick and choose which are user function and which are core system. In an array/multi-core presumably one core would spend all its time scheduling which core got what task.

¹ multiple core in some cases. OK current boards only stretch to two cores, of which we only use one but things change

Security. At present RO has none. Let’s introduce the concept of user IDs into the OS, and ownership of tasks/files/directories

I understand what you mean, however my reaction is that RO isn’t *nix. One of the points of RO is that it is in essence ‘single user’ and its up to that one user not to torch away their system or foul up. In general, no other user. Hence the concept of *nix ‘user ID’ is redundant to a large extent. I’m root, and the only user.

That said, I can see the point of a ‘protected’ mode for some parts of the system. Just as I can see the point of files being ‘lockable’ so they can’t be deleted or changed unawares. And IIRC RO does give files more than one level/kind of file protection. Don’t we have two permissions sets – user and other – that should be relevant for things like sharing over a connection, etc? And when I store files remotely elsewhere I can get more levels and user ID. So I’m not sure the User ID matters much, particularly now that many Linux distros for home use boot you straight in as one assumed user

I can however see some point to having some improvements for protecting processes and the kernel (loosely speaking) from each other. To avoid either malicious or accidental problems. However I suspect this is complicated by the mix of co-operative multitasking and being able to single task rather than the *nix pre-emption approach.

Jim

I guess it’s like Win9x’s “security model” (ie nonexistent) compared to WinNT. For all the Windows-bashing that we used to do back in the 90s, NT actually had a pretty decent security model. At least in theory. It took until NT4 for it to work properly, then NT5 (otherwise known as Win2K) for it to become useable.

As mentioned already, I don’t think we need quite the level of separation that a *nix system has. My NetBSD server here (used for development and testing) has separate users for things like Apache (runs as www), Squid (runs as squid) and the Squeezecenter software (runs as slimserver).

Samba runs initially as root, but then drops straight to running as the user who’s connected to that session.

Certainly I think RO needs some sort of elevated privilege system, so that system-wide stuff runs as “root”, and other things run as “user”. It doesn’t even need to support concurrent users.

As for pre-emption, that’s another matter. It would be lovely if it worked, combined with a compositing window manager that used double-buffering (mentioned in another thread). Having spent a long time using *nix systems, mostly as servers but with the odd workstation thrown in, I’ve grown to really like the way *nix does things. It certainly makes writing daemonised software a lot easier, eg put an extra line in inetd.conf, then your server process just reads and writes to stdin and stdout. inetd takes care of the rest.