English Amiga Board


Go Back   English Amiga Board > Main > Amiga scene

 
 
Thread Tools
Old 28 March 2015, 20:36   #61
matthey
Banned
 
Join Date: Jan 2010
Location: Kansas
Posts: 1,284
Quote:
Originally Posted by Hewitson View Post
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?
I have heard hearsay that AmigaOS 4.x now MMU write protects code sections of Amiga executables. Compilers in general don't write to code sections including on the Amiga. There probably are some exceptions especially on the 68k where assembler is used more. There are hunk section flags available which could be used to provide hints to make hunks write only. This is basically what Minuous suggested and it's a good idea not just for security but also for increased stability. Some compilers generate many small sections rather than combining like sections. Without combining, MMU pages would not be used efficiently and more memory would be wasted. At least 68k systems would need more memory before very many users would consider using write protected hunks. Write protecting a kickstart which contains a working AmigaOS and common user modules is more efficient in many ways and provides increased security and stability.
matthey is offline  
AdSense AdSense  
Old 29 March 2015, 16:34   #62
Mrs Beanbag
Glastonbridge Software
Mrs Beanbag's Avatar
 
Join Date: Jan 2012
Location: Edinburgh/Scotland
Posts: 2,202
Quote:
Originally Posted by Megol View Post
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)
It doesn't surprise me, but, i'm not really trying to "define" these terms at all. I only want to point out that the "protection domains" that various Unix/Linux processes and daemons run under are treated exactly the same way as users by the system. They appear in /etc/passwd alongside my own login accounts (my passwd file actually has 52 entries in it, and only 3 of them are people; i actually just tried logging in as "nobody" in the terminal and it worked!). They are part of the same data structures and are processed by the same functions and APIs. In all honestly i couldn't care less if they are called "users" or "eggs" or "teapots", they are the same thing inside the system.

The security idea you outlined above is essentially what modern Linux distributions do already, and they do it precisely by using the same mechanisms originally developed to support multiple users. The only important - or perhaps defining - thing about this mechanism is that it makes it possible to segregate one part of the system from another, whether that means segregating one user from another or one process from another, that's only a difference in the application of the technology.

If you had what you call a "single-user system" with "protection domains" for different processes, you could implement individual user accounts just with a set of simple scripts. Just give each script access to a separate directory and there they are. So you can cite as many academic papers as you like, the difference is... well... entirely academic. Although by all means do cite them, for our edification.

EDIT:
Quote:
Originally Posted by Megol View Post
You are right. Just got carried away. Sorry.
Yeah... me too... and i wasn't even drunk

Quote:
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.
i think it could be made *more* secure (security is always relative, even modern systems are vulnerable and we already cited side-channel attacks that cut straight through memory protection), it depends on what you want. I still think we could protect the OS from user applications by:
* having a file system with some concept of privilege level
* have a concept of privileged exec library calls
* sanitizing exec/dos library function inputs
* not giving out raw pointers to vital OS structures (perhaps give out pointers to disposable copies, and maintain a separate copy of the execbase structure for each running process)

There is also the possibility of running some sort of virtual machine, and then only running browsers &c inside that, even if you run native Amiga code outside of it as well.

EDIT2:
Ok so if you were to try to compromise an Amiga system, in a controlled way (i.e. mess with files, hijack processes &c, not just crash the system), some questions to think about:
1. if you could only use legitimate library calls or modify structures passed back as return values of same, how would you do it?
2. if you were not able to use those function calls (for instance if file permissions prevented you from doing what you wanted), how would you do it?
3. if you were not able to get the genuine addresses of the structures you wanted to modify from library calls (for instance, if you only got back a copy, which you could modify without having any effect), how would you do it?

Last edited by Mrs Beanbag; 29 March 2015 at 19:22.
Mrs Beanbag is offline  
Old 30 March 2015, 16:29   #63
idrougge
Registered User
 
Join Date: Sep 2007
Location: Stockholm
Posts: 3,076
Quote:
Originally Posted by Mrs Beanbag View Post
i don't see it in any docs, unless i'm missing something
You'll see it in the Envoy docs, or if you type "Protect ?" at the prompt. Mind you, I run Envoy on all my machines, and it replaces some of the standard DOS commands with multiuser-aware versions.

Quote:
Originally Posted by Mrs Beanbag View Post
The term "multiuser" is really a piece of history because that was the context in which the technology was originally devised, the important separation here is really not between "user" and "user" but between "user" and "root" which was always kind of special, you have "root" and then you have "user accounts" on another level.
Exactly. Strict security in operating systems appeared as a consequence of timesharing, but that doesn't mean that multiuser support is a prerequisite for strict security. You can make a multiuser system with no security at all, it just won't work for very long.

I think I'm not alone in my preference for the strictly single user philosophy of AmigaOS, yet I think it's quite possible to preserve that while introducing a higher level of security. As we both have noticed, running a UNIX-based system as the only human operator works like that on the surface -- you authenticate to do dangerous operations without ever realising you are becoming another user. In fact, for that kind of usage, the original UNIX concept of multiple timesharing users just makes it convoluted.

If one were to adhere to the usual Amiga philosophy, you would have an extra bit in the file system to imply that a file was protected, making the DOS ask you to authenticate before that file was altered. Oh, you could even have multiple "rings" of protection, but why make things complicated?
idrougge is offline  
Old 30 March 2015, 22:47   #64
Mrs Beanbag
Glastonbridge Software
Mrs Beanbag's Avatar
 
Join Date: Jan 2012
Location: Edinburgh/Scotland
Posts: 2,202
Quote:
Originally Posted by idrougge View Post
Exactly. Strict security in operating systems appeared as a consequence of timesharing, but that doesn't mean that multiuser support is a prerequisite for strict security. You can make a multiuser system with no security at all, it just won't work for very long.
Quite. At my school, we had a network and we all got user accounts, but there were no passwords except on staff accounts, and even then you could just CD into anyone's account! That was an MS-DOS network on RM Nimbuses.

Quote:
I think I'm not alone in my preference for the strictly single user philosophy of AmigaOS, yet I think it's quite possible to preserve that while introducing a higher level of security.
I don't know if i'd say that single-user is part of the "Amiga philosophy", so much as that it just wasn't much of a thing at the time. Obviously Unix was developed as a multi-user system for a very good reason but AmigaDOS, even though it was inspired by Unix in many ways, was intended for a home computer and i don't imagine anyone even thought about multi-user. Contemporary MS-DOS and Windows weren't multi-user at that time, either.

I'd say the Amiga philosophy is more about simplicity than about a lack of any particular functionality. It might be possible to do multi-user in an "Amiga-like way". Although to be honest there probably wouldn't be much demand! But i think it would be nice to have.

Maybe security could work in such a way that a program can only write to the (protected) directory (and its subdirectories) it was launched from (that is, its current working directory at startup, not the path of the executable itself), unless some other process passes it a lock to something else. Then "user accounts" would just be normal directories that a login application could manage. So it could run a workbench session from whatever you decided was your home directory and then you wouldn't be able to write outside of it, and if you don't want multi-user, just don't bother running a login manager.
Mrs Beanbag is offline  
Old 31 March 2015, 00:39   #65
idrougge
Registered User
 
Join Date: Sep 2007
Location: Stockholm
Posts: 3,076
Quoting the readme for FastFileSystem v43.20:
Quote:
Added 64 bit support according to the new style device based
trackdisk64 standard. Notification should work well now for
SetComment, SetFileDate, SetProtection, and SetOwner.
Added UID/GID identification support via Envoy for symmetry.

...

Envoy accounts support is only available if accounts.library is
already loaded.
idrougge is offline  
Old 31 March 2015, 01:54   #66
saimon69
Bedroom musician

 
Join Date: Apr 2014
Location: los angeles,ca
Posts: 701
Quote:
Originally Posted by Minuous View Post
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.
Well if you have the skills you can fork AROS 68k and test how will come out, or maybe try to join with a coder; if works i think code can be merged again
saimon69 is offline  
Old 31 March 2015, 03:12   #67
kolla
Registered User
kolla's Avatar
 
Join Date: Nov 2007
Location: Trondheim, Norway
Posts: 767
Mind you all - the origin of this discussion was "Let us make AmigaOS mainstream again!!", and I pointed out that noone _want_ to see a system as wide open as AmigaOS gain popularity. Then the argument circulated back to "but we do not need security - noone will attack us, because we are not mainstream!". The discussion pretty much was derailed by a an argument about semantics, but whatever. The original idea here was, how could one create an operating system that is secure and modern, yet still be AmigaOS. For me, OSX is pretty much already there, except the UI is not how I want it.
kolla is offline  
Old 31 March 2015, 17:15   #68
idrougge
Registered User
 
Join Date: Sep 2007
Location: Stockholm
Posts: 3,076
To me, OSX is very far away from what is desirable in a modern AmigaOS-like system. As soon as you scratch on the surface, you find ugly UNIX groundwork which literally screams "hands off" at you.

If there is one thing which isn't part of the Amiga philosophy, it's "user friendliness through obscurity". No current operating system has the equivalent of the Amiga's DEVS:, S:, L: or LIBS:, instead opting to hide away everything that makes the system tick.
idrougge is offline  
Old 31 March 2015, 21:21   #69
Megol
Registered User

Megol's Avatar
 
Join Date: May 2014
Location: inside the emulator
Posts: 254
I agree, for me the beauty of the Amiga OS is that one can actually understand it. That the parts complement each other and build into something more.
In many ways is more Unix than Unix (;P) in that the "do one thing and do it well" philosophy goes far deeper in the actual implementation.

But to be realistic there are many warts and problems deeply ingrained into it too. There isn't IMHO much to salvage from it code wise, what is still worth a lot inspirationally is the integration and composability. That's the reason I liked the idea of a new generation "Amiga" based on QNX but that was not to be. :/
Actually even using the Windows NT kernel could give good results. The majority of ugliness of Windows is in the upper layers like the Win32/Win64 subsystems.
Megol is offline  
Old 31 March 2015, 23:54   #70
Mrs Beanbag
Glastonbridge Software
Mrs Beanbag's Avatar
 
Join Date: Jan 2012
Location: Edinburgh/Scotland
Posts: 2,202
Quote:
Originally Posted by idrougge View Post
If there is one thing which isn't part of the Amiga philosophy, it's "user friendliness through obscurity". No current operating system has the equivalent of the Amiga's DEVS:, S:, L: or LIBS:, instead opting to hide away everything that makes the system tick.
Are /etc, /var, usr/bin and usr/lib really that different?

Windows is pretty obtuse, though, and most user software doesn't seem to bother with shared libraries at all. It's possible to do, i gather, but it's such a pain in the ass that developers typically just bundle all their DLLs with the executable, which kind of defeats the point really. And what about those drive letters? Imagine trying to explain to a kid why the main hard disk is C: and not A:.

Another idea i had previously for a secure, multi-user OS is to use some sort of Union Filesystem so that it appears to all users that they are in a single-user OS with complete access to everything... except really they haven't. So each user account is kind of like a different version or branch of the entire system.

What actually is this "Envoy" thing, anyway? I never heard of it before, is it OS3.9? Is it official or 3rd party?

Last edited by Mrs Beanbag; 01 April 2015 at 00:04.
Mrs Beanbag is offline  
Old 01 April 2015, 10:16   #71
idrougge
Registered User
 
Join Date: Sep 2007
Location: Stockholm
Posts: 3,076
Quote:
Originally Posted by Mrs Beanbag View Post
Are /etc, /var, usr/bin and usr/lib really that different?
Well, do an "ls usr/bin" or "ls usr/lib" and tell me what the files there do. Oh, go ahead and use "man" if you like, it tells you all you ever wanted to know.
Or why not try to use "cp" to copy files and look what happens to your metadata.

Quote:
Originally Posted by Mrs Beanbag View Post
Windows is pretty obtuse, though, and most user software doesn't seem to bother with shared libraries at all. It's possible to do, i gather, but it's such a pain in the ass that developers typically just bundle all their DLLs with the executable, which kind of defeats the point really. And what about those drive letters? Imagine trying to explain to a kid why the main hard disk is C: and not A:.
Not to mention that the files are called "MRXZYZPTLK.DLL" and are stored as far away from the user as possible.

Quote:
Originally Posted by Mrs Beanbag View Post
What actually is this "Envoy" thing, anyway? I never heard of it before, is it OS3.9? Is it official or 3rd party?
Envoy is (was) Commodore's local network system for the Amiga. After Commodore, the rights were taken over by IAM and Schatztruhe, so you could say it's both official and third party. The last maintainer was quite involved in AmigaOS v42+.

If you're only used to the AmiTCP way of networking, you'll be surprised by how much more Amiga-like Envoy is.
idrougge is offline  
Old 01 April 2015, 13:23   #72
hceline
Registered User
 
Join Date: Nov 2009
Location: Top of the world
Posts: 34
Quote:
Originally Posted by idrougge View Post

Envoy is (was) Commodore's local network system for the Amiga. After Commodore, the rights were taken over by IAM and Schatztruhe, so you could say it's both official and third party. The last maintainer was quite involved in AmigaOS v42+.

If you're only used to the AmiTCP way of networking, you'll be surprised by how much more Amiga-like Envoy is.
And also the most underrated Amiga software that ever existed.
If only muFS had agreed with Envoy about the UID of root from the very beginning.......
hceline is offline  
Old 01 April 2015, 22:39   #73
Mrs Beanbag
Glastonbridge Software
Mrs Beanbag's Avatar
 
Join Date: Jan 2012
Location: Edinburgh/Scotland
Posts: 2,202
Quote:
Originally Posted by idrougge View Post
Well, do an "ls usr/bin" or "ls usr/lib" and tell me what the files there do.
I find most of what's in there fairly straightforward as long as you know what the different things are. Package names can often be a little obtuse, but that's nothing to do with where they are... usr/lib stores all the DLLs for all the software. usr/bin stores all the executables. The problem on Linux is just that there are so many of these things, and it's not very nice to have all the executables in one place like that (and mixing system binaries with user applications, too).

It's neat that the Amiga lets you install applications pretty much anywhere you want in the filesystem. I like that. Of course it would make package management quite difficult. But we can think about that another time maybe.
Mrs Beanbag is offline  
Old 02 April 2015, 18:40   #74
idrougge
Registered User
 
Join Date: Sep 2007
Location: Stockholm
Posts: 3,076
I think package management is a "solution" to a problem which would be better solved by removing the problem altogether.

Of course, the Amiga's handling of applications is also far from optimal. To begin with, there is no notion of applications whatsoever, as far as the OS is concerned. The Commodities system was a good start, though.
idrougge is offline  
Old 02 April 2015, 18:52   #75
Hewitson
Registered User
Hewitson's Avatar
 
Join Date: Feb 2007
Location: Melbourne, Australia
Age: 35
Posts: 2,235
Quote:
Originally Posted by idrougge View Post
To me, OSX is very far away from what is desirable in a modern AmigaOS-like system. As soon as you scratch on the surface, you find ugly UNIX groundwork which literally screams "hands off" at you.
What a load of rubbish. The OSX userland is derived from FreeBSD and it couldn't be easier to configure if it tried.

If configuring a simple text file is "ugly" to you, you'd better stick to the piece of shit known as Window$.
Hewitson is offline  
Old 02 April 2015, 22:29   #76
Mrs Beanbag
Glastonbridge Software
Mrs Beanbag's Avatar
 
Join Date: Jan 2012
Location: Edinburgh/Scotland
Posts: 2,202
Quote:
Originally Posted by idrougge View Post
I think package management is a "solution" to a problem which would be better solved by removing the problem altogether.

Of course, the Amiga's handling of applications is also far from optimal. To begin with, there is no notion of applications whatsoever, as far as the OS is concerned. The Commodities system was a good start, though.
I never liked package management when i first started using Linux, but i do like the fact that when you install a package it installs all its dependencies as well. It would be nice if there were some quick way to query an executable to find which libraries it needs. Maybe a special hunk in the executable could contain such a list? But this is getting a bit off-topic.
Mrs Beanbag is offline  
Old 03 April 2015, 03:07   #77
kolla
Registered User
kolla's Avatar
 
Join Date: Nov 2007
Location: Trondheim, Norway
Posts: 767
Idrougge: you are aware that there is nothing "amiga philosophy" about AmigaOS filesystem layout, and that S:, L:, T: etc are legacy from a different OS, namely TRIPOS? The original genuine Commodore Amiga Operating System, CAOS, has been said to be much more UNIX like interms of filesystem layout. Imagine how different things could have been if CAOS was implemented and TRIPOS never was used. It would also have simplified the path forward a lot.
kolla is offline  
Old 03 April 2015, 11:26   #78
Locutus
Registered User

 
Join Date: Jul 2014
Location: Finland
Posts: 768
Quote:
Originally Posted by Mrs Beanbag View Post
I never liked package management when i first started using Linux, but i do like the fact that when you install a package it installs all its dependencies as well. It would be nice if there were some quick way to query an executable to find which libraries it needs. Maybe a special hunk in the executable could contain such a list? But this is getting a bit off-topic.
standard tool really, just do something like this:

locutus ▶ Malacoda ▶ ~ ▶ $ ▶ ldd (which ls)
linux-vdso.so.1 (0x00007fffcbbf5000)
libselinux.so.1 => /lib/x86_64-linux-gnu/libselinux.so.1 (0x00007fe486383000)
libacl.so.1 => /lib/x86_64-linux-gnu/libacl.so.1 (0x00007fe48617a000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fe485dd0000)
libpcre.so.3 => /lib/x86_64-linux-gnu/libpcre.so.3 (0x00007fe485b62000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fe48595e000)
/lib64/ld-linux-x86-64.so.2 (0x00007fe4865ea000)
libattr.so.1 => /lib/x86_64-linux-gnu/libattr.so.1 (0x00007fe485758000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fe48553b000)

And you see which shared libraries it links to.

Ofcourse this doesnt map to what actual packages it requires, so you can do (on Debian)

locutus ▶ Malacoda ▶ ~ ❯ tmp ❯ tree ▶ $ ▶ apt-cache showpkg e-uae|tail -n 5
Dependencies:
0.8.29-WIP4-10 - libatk1.0-0 (2 1.29.3) libc6 (2 2.3) libcairo2 (2 1.2.4) libfontconfig1 (2 2.8.0) libfreetype6 (2 2.2.1) libglib2.0-0 (2 2.16.0) libgtk2.0-0 (2 2.8.0) libpango1.0-0 (2 1.14.0) libsdl1.2debian (2 1.2.10-1) zlib1g (2 1:1.1.4)

And you see a list of all direct dependencies.

Now if you want to see the whole graph visually you can do:

debtree e-uae | dot -Tpng >e-uae.png and get this:

http://http://locutus.puscii.nl/e-uae.png

Last edited by Locutus; 03 April 2015 at 11:37.
Locutus is offline  
Old 03 April 2015, 14:52   #79
daxb
Registered User
 
Join Date: Oct 2009
Location: Germany
Posts: 1,751
On Amiga there is ResourcesManager. http://aminet.net/package/util/app/RscManager
daxb is offline  
Old 03 April 2015, 17:34   #80
idrougge
Registered User
 
Join Date: Sep 2007
Location: Stockholm
Posts: 3,076
Quote:
Originally Posted by Hewitson View Post
What a load of rubbish. The OSX userland is derived from FreeBSD and it couldn't be easier to configure if it tried.
That's the problem; it doesn't even try. So Apple try to make up by hiding it from you, wrapping it inside layer upon layer of abstraction.

Quote:
Originally Posted by Hewitson View Post
If configuring a simple text file is "ugly" to you, you'd better stick to the piece of shit known as Window$.
Or that piece of shit called Amiga, mind you. You know, the VT100 terminal is 40 years old now, but it is still state-of-the-art in UNIX land.
idrougge is offline  
AdSense AdSense  
 


Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
 
Thread Tools

Similar Threads
Thread Thread Starter Forum Replies Last Post
Breathless security codes Supamax request.Other 9 09 October 2009 08:11
SNES EyeOfTheBeholder compared to Amiga's port jharrison Retrogaming General Discussion 12 01 December 2008 23:06
How fast is WINUAE compared to a real amiga? mrbob2 Retrogaming General Discussion 13 15 November 2008 00:14
My Amiga was a security system DigitalQuirk Nostalgia & memories 3 17 April 2008 18:39
Why are Amiga games the most cheat menu hacked compared to other systems? extentofmysin Retrogaming General Discussion 13 06 September 2006 21:16

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +2. The time now is 00:05.


Powered by vBulletin® Version 3.8.8 Beta 1
Copyright ©2000 - 2017, vBulletin Solutions, Inc.
Page generated in 0.35385 seconds with 11 queries