Amiga security compared to other OS

[kolla]

I am tired of people missunderstanding the concept of "user", and hence also multiuser, apparently on purpose just to derail the discussion.

Megol:
So, no "users", but "domains", sounds like someone's been playing with SELinux, is that what you are suggesting? A sort of "root only SELinux" type of security model?

[Mrs Beanbag]

me too, well said.

i was trying to work out how exactly the CPU accesses the IDE interface, i downloaded the open source scsi.device but i can't extract the lzx file on my PC.

Originally Posted by kolla

Well, you can also use a MUFS capable filesystem and enjoy more levels of "protection", but it is kinda moot as long as all memory is wide open for any software.

It is not entirely moot, there is a lot of interest now in how to do security on embedded systems, since there are now low-power CPUs in everything.

Also "all memory" might not actually be wide open for any software, given certain caveats... it would certainly be possible, i have discovered today, to design an accelerator card that distinguished between supervisor and user accesses to Fast RAM, as well as between data and instruction fetches. So it is certainly possible to get some very basic memory protection even with a 68020-based accelerator (or even just a RAM expansion, come to that), given an appropriately-modified ROM.

[Megol]

Personally I'm tired of arrogant people that have to be spoon-fed.

Simple example (to do it in more detail would take a long time):
Start computer, OS owns all rights, drivers and subsystems/daemons started with the rights given to them.
User is in control, he starts a program which uses the default rights given to it. The program wants to check for updates but doesn't have the rights to access the Internet. It is halted and the user is prompted to either allow or disallow Internet access. The user accepts the access and the program continues.
...
There is no need to separate each part into a user to give them separate rights. That's all I've said and all I meant.

[kolla]

Well, how do you implement that? If you look at iOS and Android which do what you describe, sandboxing each and every app in their own little sandbox, running as "user", and grant access and rights to certain resources for each sandbox, either as "user" (you, interactively), or through "superuser" (root, non-interactively). Point is, you still need the concept of "users", if not, _everything_ runs as superuser, and you do not want that.

[Megol]

Superuser... You still can't imagine a security model that isn't Unix. Have it your way, no skin of my nose.

[Locutus]

Superuser, well its just what you want to call it.

Various non-UNIX's refer to it as SYSTEM, MNGR, Supervisor, Operator, 0.0, etc

Amusingly enough, they all implement very similar multiuser security paradigms.

[Megol]

Originally Posted by Locutus

Superuser, well its just what you want to call it.

Various non-UNIX's refer to it as SYSTEM, MNGR, Supervisor, Operator, 0.0, etc

And? Have you tried reading anything I've written in this thread?

Amusingly enough, they all implement very similar multiuser security paradigms.

Very amusing. Not.

Does the fact that many systems use the multiuser system for security make that the only model available as was the original claim*? No. Nor does it make it a bad model - I surely haven't claimed it is.

(* "Multiuser does not mean multiple people using one computer, it means multiple layers of security, where different "users" (owners of processes) have different access to resources such as memory, storage and everything. Without this in place, a system should not really be exposed to Internet.")

[Minuous]

Here's my proposal for adding memory protection and resource tracking to AmigaOS: http://amigan.1emu.net/releases/ami-code.txt (relevant part is at end of document).

I'm not sure why none of the AmigaOSes have implemented this yet, it should work fine as described for old and new software, unless there is some issue I have overlooked. Comments and criticisms of this proposal are welcomed.

[Mrs Beanbag]

Originally Posted by Megol

Start computer, OS owns all rights,

But that's just what "superuser" means in Unix...

drivers and subsystems/daemons started with the rights given to them.
User is in control, he starts a program which uses the default rights given to it. The program wants to check for updates but doesn't have the rights to access the Internet. It is halted and the user is prompted to either allow or disallow Internet access. The user accepts the access and the program continues.
...
There is no need to separate each part into a user to give them separate rights. That's all I've said and all I meant.

Ok but all you've done is make the programs be the "users".

There is nothing about "multi-user" that requires that the "users" be human beings. It is an abstract concept.

Anyway i think there is some confusion between the terms "single user" and "multi-user" because the word "user" means something different in each case. A "single user OS" is really one that has no concept of users at all; it is a "userless OS".

Originally Posted by Minuous

Here's my proposal for adding memory protection and resource tracking to AmigaOS: http://amigan.1emu.net/releases/ami-code.txt (relevant part is at end of document).

I'm not sure why none of the AmigaOSes have implemented this yet, it should work fine as described for old and new software, unless there is some issue I have overlooked. Comments and criticisms of this proposal are welcomed.

Don't feel left out, my proposals are being ignored too, it seems we'd all rather just argue about what "multi-user" means until judgement day.

I broadly agree with your suggestions, and have thought about such ideas myself, however i don't agree that most OS3 users have an MMU, a stock A1200 doesn't have one. I'm very interested in the possibilities for security without one, though. We might not be able to stop people writing willy-nilly to other program's memory if they are that naughty, but there are serious security holes in the Exec library itself. Currently you don't even need to play dirty to compromise a system.

[Minuous]

>however i don't agree that most OS3 users have an MMU, a stock A1200 doesn't have one.

A stock A1200 can't run any modern version of AmigaOS (eg. OS3.9) anyway. And memory protection would be disabled for non-MMU systems, that doesn't mean MMU-equipped systems should be held back. That's a bit like not supporting AGA because some systems only have OCS.

>I'm very interested in the possibilities for security without one, though.

Not really feasible to have security without one. Only way would be to run all programs via a CPU emulator, which would intercept memory accesses and do MMU-esque handling of such accesses. That would work in theory but performance would be awful.

>but there are serious security holes in the Exec library itself.

Yes, some combination of API argument checking and/or fixes to eg. buffer overflow vulnerabilities that some OS functions have would be required before the system could be considered fully secure.

[Mrs Beanbag]

Originally Posted by Minuous

A stock A1200 can't run any modern version of AmigaOS (eg. OS3.9) anyway. And memory protection would be disabled for non-MMU systems, that doesn't mean MMU-equipped systems should be held back. That's a bit like not supporting AGA because some systems only have OCS.

Oh i entirely agree. But i still like to think about what can be done with a stock A1200, or even a stock A500 come to that (or at least, one with a 68010 installed).

Not really feasible to have security without one. Only way would be to run all programs via a CPU emulator, which would intercept memory accesses and do MMU-esque handling of such accesses. That would work in theory but performance would be awful.

Security is always relative, there will always be some way to compromise a system if someone is willing to try hard enough. An Amiga without an MMU can certainly be more secure than they currently are. A filesystem with some notion of user/system access levels could make it harder to compromise by OS-legal means. And i have mooted the possibility of RAM expansions that separate Supervisor and User address spaces.

Yes, some combination of API argument checking and/or fixes to eg. buffer overflow vulnerabilities that some OS functions have would be required before the system could be considered fully secure.

And that's not all. There are library functions that can be used to do all sorts of sinister things even with valid arguments, functions that allow one to patch OS calls, or enter the Supervisor CPU state. We should have some concept of privileged Exec functions. Also functions often give out addresses of structures that, if modified, could wreak havoc. With no memory protection of course in theory it would be possible to scan the entire RAM to find these sorts of things but currently things really are far too easy for any would-be hacker.

[Ami_GFX]

I spend a good deal time on a forum dedicated to computer security. This is the first time I've seen some of this stuff discussed regarding the Amiga. Quite a discsussion since I last look a look at this thread. While Amiga OS is quite vulnerable in a lot of ways, the security by obscurity is a real detterent. It isn't likely that there would be any real threats against it. Exploiting an Amiga would require some real programming skills and knowledge of the inside of of Amiga OS. While not impossible, there would be no money it it and very little motivation. Would there be any data inside the typical Amiga user's machine worth stealing? The only thing of value is likely to be the Amiga itself and the best security for that is going to be a burglar alarm and an insurance policy. That presumes a burglar who knew what Amigas are worth. Once again security by obscurity kicks in. While those of us in the Amiga scene know this, those outside aren't nearly as likely to know that that box sitting over there is an A4000 and not a PC that has almost no resale value.

The other thing that the Amiga has going for it is simplicity and small data footprint. In the unlikely event that something happens and the system is corrupted, restoring it is quite simple. On the PC side, I use specialized imaging software to do this. With an Amiga, I just copy the OS and Work partitions to another drive with a CLI command.

"Copy Work: To Jaz1:Backup/Work ALL" is all that is necessary to completly back up a work partition to a Jaz drive. To restore it just reverse source and destination. You can also use Winuae to completely image an Amiga's disk and then you can boot the image in Winuae to do the restore. Aren't Amigas wonderful.

[Megol]

Originally Posted by Mrs Beanbag

But that's just what "superuser" means in Unix...

No there are huge differences, sure you could call that "superuser" but that's not the usual definition of the term.
Supervisor would perhaps be used to describe that initial state but even that is stretching.

(If anything my example have the actual user as superuser as he/she is the one that can give rights to others)

Ok but all you've done is make the programs be the "users".

Only if you currently are calling programs "users". That isn't the usual definition of users but...

There is nothing about "multi-user" that requires that the "users" be human beings. It is an abstract concept.

Anyway i think there is some confusion between the terms "single user" and "multi-user" because the word "user" means something different in each case. A "single user OS" is really one that has no concept of users at all; it is a "userless OS".

It is you that applies the term user to anything that have privileges.

It is you that claims a system with several privileged entities is a multi-user system.

But that is just you redefining terms. Not me confusing things.

The result is a kind of reverse no true Scotsman, whatever I describe you just reply "that's a Scotsman" ignoring the normal definition (someone from Scotland).

This isn't productive as a discussion, I hope it have been productive for someone interested in security models though.

http://en.wikipedia.org/wiki/Multi-user
http://www.merriam-webster.com/dictionary/multiuser

[jimbob]

Excuse my ignorance but I don't understand the disagreement here. Everyone gets that a user doesn't necessarily mean a human at the console so why fight over whether some programmed abstraction with or without certain privileges is called a user or not.

I don't know the gory details but even just looking at process explorer in windows it seems pretty clear that my user account is something different from SYSTEM, LOCAL SERVICE or NETWORK SERVICE.

Aren't you just agreeing that the term user is beyond stretched?

[Mrs Beanbag]

Originally Posted by Megol

No there are huge differences, sure you could call that "superuser" but that's not the usual definition of the term.
Supervisor would perhaps be used to describe that initial state but even that is stretching.

(If anything my example have the actual user as superuser as he/she is the one that can give rights to others)

Since you are linking to Wikipedia, i take it you accept its authority on these things, so i'll quote the article on "superuser":

In Unix-like computer OSes, root is the conventional name of the user who has all rights or permissions (to all files and programs) in all modes (single- or multi-user).

The first process bootstrapped in a Unix-like system, usually called init, runs with root privileges. It spawns all other processes directly or indirectly, which inherit their parents' privileges. Only a process running as root is allowed to change its user ID to that of another user; once it's done so, there is no way back.

Originally Posted by Megol

Only if you currently are calling programs "users". That isn't the usual definition of users but...

It is you that applies the term user to anything that have privileges.

It is you that claims a system with several privileged entities is a multi-user system.

No... everyone else in this thread is trying to tell you this.

A "user" as far as the operating system design is concerned, is a set of privileges. Whether these sets of privileges are actually used by human beings or not is neither here nor there, a computer doesn't even know what a human being is.

Hence the confusion. Because in the real, outside world we think of a user as a human being. But there are not any human beings in an operating system.

Here is a list of some "users" currently running processes on my Linux PC, that are not human beings:
daemon
kernoops
whoopsie
nobody
timidity
colord
rtkit
syslog
avahi
messagebus

[Megol]

Incredible...

It may surprise you but I have several years of education in the area at the university level. I have never seen a paper that uses your definitions (and I have read a lot), I have never had a lecturer being even close to your definition. Even from other student have I ever heard anything like that.

No operating system papers uses your definitions for either user or multi-user. Research in security systems including capability systems doesn't mix the idea of users and protection domains*. You are completely on your own.

(* or whatever term is used to describe a privileged component)

[Vot]

Good god you guys are talking #hit. Stop arguing semantics. All versions of amiga os have security that can best be described as laughable. Case closed.

[Megol]

Originally Posted by Vot

Good god you guys are talking #hit. Stop arguing semantics. All versions of amiga os have security that can best be described as laughable. Case closed.

You are right. Just got carried away. Sorry.

IMHO it is impossible to patch Amiga OS to be either protected or secure. But it wouldn't be impossible to make an OS that is very similar but protected (though not secure) by making all memory readable but protecting writes using virtual memory.

[Hewitson]

I hate to bring up something in this thread that might actually be worth discussing, but how does the security in OS4 and MorphOS compare to that of the classic AmigaOS? Has there been many improvements made in that area?

[Photon]

I'm perfectly fine with 3.1. Sometimes a neat handler or utility will be more useful to me than would an OS3.2 for 68k or similar. Just adds more usefulness, while OS upgrades focus on other things, like emulating much later OSes with things you absolutely don't need. An OS just needs to do one thing, really. Navigate to a folder and allow me to double-click an icon to open a program.

I think it's wrong to insert hardware that doesn't use or belong to the original hardware design to run an almost modern OS remake slowly. I think it makes more sense to leave the platform entirely and run it on really fast hardware, and have as goal to make a really good OS the way you want it.

Part of the problem is Workbench was already (for the usability part in my first paragraph) like the modern windowed OSes. So you could say it was already fine. It would be nice to "surf the web", but if it doesn't "do Youtube and Facebook" you're already looking at hardware requirements that needs GHz and GB of RAM or it'll crawl. It's about expectations.

A really tight unified socket library for 3.1 is different now, that would be useful for FTP, IRC, etc.