During my work at rebuilding usergroup.library for MorphOS i was thinking about finding a better use for it than stupid emulation. The following comcept came to my mind, i'd like to discuss it here. This is just a concept and just a discussion, currently i have no time to work in this direction, but if there'll be someone who wishes to try to implement this idea i can open usergroup.library source code immediately (well, it's even not a part of network stack at all, just plain add-on, it is not used by the stack itself, only by inetd and ixemul.library) on Unmorphos CVS and give an access rights to use it as a starting point for the development.
The main idea is: we want to have some services, accessible from outside, may be even telnet or ssh accounts, and we want to protect our system. Full implementation of UNIX-alike access control is impossible under MorphOS because we can implement access control for files in the filesystem, but we can't implement it for IPC (signals, messages and ports), this renders the whole system useless because every user can ask another user's application to do something bad.
But there's a possibility to limit user's activity in the system using policy-based access control like in Windows NT (and derivatives). For example, we could have some set of rules for every user like:
- forbid/permit starting binaries from specified directory.
- forbid/permit using graphical applications (graphical application will always open intuition.library), useful for remote CLI accounts.
- forbid/permit reading/writind/deleting files in specified directory (can be implemented in the filesystem level or dos.library level - can be discussed)
- forbid/permin entering specified directory.
- etc
This would allow to create some trusted environment (unique home directory and set of harmless programs to run) for every user and lock the user within this environment so that it won't be able to go outside.
Anyone is welcome to say what he thinks about it.

Sounds good, but I'd prefer a safe system over
a feature-rich system.

Well... in my opinion it would never be safe.

Do you mean "never install servers on MorphOS"?
Anyway, sometimes it's really needed, at least for yourself. Of course, *ANY* networked system is potentially unsafe...

Quote:

Good point, look at Windows...

AmigaOS API based things are even more unsafe...

Quote:

I second itix' opinion. If it's not going to completely serve its purpose (bring security), it's not worth putting resources into developing it.
I once had some ideas about making AmigaOS multiuser, but not related to securuty (in my opinion, wasted time, and more complexity and obstacles): It consisted just in having different configurations, by swapping ENV: and ENVARC: assigns. This way, each user could have its own system configuration.
But many programs do not use ENV to store its configuration. Anyway, having separate configurations por each user is rarely appreciated. I deal with this every day, our company's computers use generic identities (the employees position), and life is much easier for everybody.

MorphOS 2.2 has the support software for crypting entire partitions...

Now if could be implemented from Smart/Open firmware the option for inserting password and then jumping directly to the start partitions that were before crypted from MOS 2.2, then you will have direct pseudo-multiuser facility feature...

Sort like this

From Open Firmware prompt:

1) Open-Firmware <- interrogating -> Logging program present in main FFS partition

2) Open Firmware <- thru logging program -> Reading list of various crypted partitions

3) User log-in

4) After receiving password the Logging program tells Open Firmware to recognize user and to jump to his/her related crypted partition, and boot from it...

5) At any reboot system loses information from logged-in user...

I think that this is an easy multiuser facility trick that could be implemented...

Remember that it is not possible a change log "on the fly"...

You can't leave the system and insert a new password and let other persons to use the machine and then get back to previous user...

Any new user should wait for a reboot to log (or log again) to enter his/her own partition with his/her personal settings, and his/her own data, installed software and utility programs, etcetera...

[ Edited by Raf_MegaByte on 2009/1/15 14:10 ]

when talking about 'pseudo multi user' features... i'd be satisfied with simple 'basic' ambient start, and to enable disabled partitions with some password, this could be just a simple ambient/dos feature...

bye, MarK.