• Welcome to OS2World OLD-STATIC-BACKUP Forum.
 

News:

This is an old OS2World backup forum for reference only. IT IS READ ONLY!!!

If you need help with OS/2 - eComStation visit http://www.os2world.com/forum

Main Menu

Security/2 in eComStation 2.0

Started by jep, 2011.04.18, 10:51:57

Previous topic - Next topic

jep

Hello,

I've tried Security/2 (0.4.5) with eComStation 2.0 GA and found it to be very interesting and with potential.
It seem to allow us to add secured login to the desktop and possibly multiple WPS desktops (1 per user).

There are however some things that remain unclear to me, that I need to ask you for guidance.
As mentioned by others in the original topic from 2007, I also have problems to set the HOME environment variable (system doesn't use it), it use the OS2 folder by default and it seem to me that one need to copy/create e.g. os2.ini and os2ini.ini to the folder one set as the user directory?!

Another ting, am I supposed to edit the acls-file by hand to allow/deny access various tools and folders?
Is there an editor (GUI, preferaply WPS integrated and then I mean not just a plain text editor) somewhere that can simplify the configuration task?

I'd like to set one account to allow me to start the DOS Command line, but that is not possible as it denies it. What setting should I use? An editor or documentation by example would be nice to have.

//Jan-Erik

StefanZ

#1
Hello jep,

please see below my experiences during the past years:

Quote from: jep on 2011.04.18, 10:51:57
Hello,

I've tried Security/2 (0.4.5) with eComStation 2.0 GA and found it to be very interesting and with potential.
It seem to allow us to add secured login to the desktop and possibly multiple WPS desktops (1 per user).

There are however some things that remain unclear to me, that I need to ask you for guidance.
As mentioned by others in the original topic from 2007, I also have problems to set the HOME environment variable (system doesn't use it), it use the OS2 folder by default and it seem to me that one need to copy/create e.g. os2.ini and os2ini.ini to the folder one set as the user directory?!


The HOME variable is pre-set with the new user (and password) being created and has to be changed manually to something reasonable. All this you can find stored in file ?:\ecs\SYSTEM\SESS\etc\passwd.

My example look like this:
root:$1$K2hF$IbJXjkDPrAesJnz3rYA5s/:0:0::$C\HOME\ROOT:$C\OS2\CMD.EXE:$C\OS2\CMD.EXE:
test:$1$K2hF$igrk4vs2yp38nMD8Gh0MK1:100:0::$C\OS2:$C\OS2\CMD.EXE:$C\OS2\CMD.EXE:

So for the first user - root - HOME directory is set (and working!) to C:\HOME\ROOT, and for the user test is is pre-set to C:\OS2.

For os2.ini and os2sys.ini: yes, you have to create a new set of these files in the HOME directory for each of the users (or copy the current versions from ?:\OS2). This is actually a good thing, since this allows for each user to have his/her "personalized" settings stored into his/her personal HOME directory for each of the desktops.
Note: Although I tried really hard, I was never able to fully duplicate the existing desktop to more functional copies! :( Hints on this are welcome!!

Hint: to set additional environment variables for the current user create a file called "environment" in the HOME dir for the current user. My example of C:\HOME\BOLDOS\environment file contents:

DESKTOP=C:\Desktop
USER_INI=C:\HOME\BOLDOS\OS2.INI
SYSTEM_INI=C:\HOME\BOLDOS\OS2SYS.INI
MOZILLA_HOME=C:\HOME\BOLDOS

By this, user BOLDOS has i.e. separately stored profile info and files for Firefox browser.

Quote
Another ting, am I supposed to edit the acls-file by hand to allow/deny access various tools and folders?
Is there an editor (GUI, preferaply WPS integrated and then I mean not just a plain text editor) somewhere that can simplify the configuration task?

There is no such thing as dedicated ACLS editor nor there is any GUI application to do that. Moreover (since SESS is only a layer or drivers and a bunch of some basic cmd line utilities), there is no integration of SESS into desktop to speak of. Unfortunately SESS does not seem to be a fully finished product. This means until a) GUI utilities are created and more importantly b) it gets integrated into desktop by Mensys in some future version of eCS, we are stuck with the bunch of utilities we have and manual editing of cfg files :)

There are also some other minor issues, such as this one:
I was thinking to lessen the rights to vital parts of the system, so that user has only i.e. read and execute rights to vital system directories such as C:\OS2, C:\ecs, C:\MPTN etc. Unfortunately, the desktop seems to require write access to C:\OS2\os2.ini and/or C:\OS2\os2sys.ini (do not now remember to which one), even if you have separate copies stored in HOME dir for the current user. As a result, you are given a warning message by desktop every 1 minute that desktop cannot write access the file C:\OS2\os*.ini. Most probably this can be overcome, unfortunately for me I have not found a way.

Quote
I'd like to set one account to allow me to start the DOS Command line, but that is not possible as it denies it. What setting should I use? An editor or documentation by example would be nice to have.

//Jan-Erik

Yes, it seems to be possible to run DOS command line only when logger in as root. I believe this is due to the limitations of SESS subsystem, since it is not able to process the correct APIs, thus if you are logged as any other user than root, SESS will not "allow" to run DOS. If you are logged as root, then I believe you have full system access by default, thus the limitation of SESS not being able to control the correct APIs does not apply and the system will run the DOS cmd line just fine.

For the documentation:
it actually exists, in C:\ecs\SYSTEM\SESS\doc. there is a good explanation + some examples. The rest is trial and error :)

Please let me know your thoughts and further experiences, I would be quite interested to know your progress :)

Stefan

jep

Thank you StefanZ,

you confirmed and explained most of the questions I have about it.
Quote from: StefanZ on 2011.04.18, 22:47:22
The HOME variable is pre-set with the new user (and password) being created and has to be changed manually to something reasonable. All this you can find stored in file ?:\ecs\SYSTEM\SESS\etc\passwd.

My example look like this:
root:$1$K2hF$IbJXjkDPrAesJnz3rYA5s/:0:0::$C\HOME\ROOT:$C\OS2\CMD.EXE:$C\OS2\CMD.EXE:
test:$1$K2hF$igrk4vs2yp38nMD8Gh0MK1:100:0::$C\OS2:$C\OS2\CMD.EXE:$C\OS2\CMD.EXE:
I used the user command to set ?:\ecs\SYSTEM\SESS\etc\passwd
as a plain installation look like this:
root:$1$K2hF$IbJXjkDPrAesJnz3rYA5s/:0:0::$C\OS2:$C\OS2\CMD.EXE:$C\OS2\CMD.EXE:
test:$1$K2hF$igrk4vs2yp38nMD8Gh0MK1:100:0::$C\OS2:$C\OS2\CMD.EXE:$C\OS2\CMD.EXE:

and added
user1:$1$K2hF$igrk4vs2y79tyJKJKLsdfg1:100:0::$C\HOME\USER1:$C\OS2\PMSHELL.EXE:$C\OS2\CMD.EXE:

so that it would boot to a useful desktop instead of the (yuck) VIO command line window.

Quote from: StefanZ on 2011.04.18, 22:47:22
So for the first user - root - HOME directory is set (and working!) to C:\HOME\ROOT, and for the user test is is pre-set to C:\OS2.

For os2.ini and os2sys.ini: yes, you have to create a new set of these files in the HOME directory for each of the users (or copy the current versions from ?:\OS2). This is actually a good thing, since this allows for each user to have his/her "personalized" settings stored into his/her personal HOME directory for each of the desktops.
Note: Although I tried really hard, I was never able to fully duplicate the existing desktop to more functional copies! :( Hints on this are welcome!!

Yes, would be nice to have different desktops like that.
Couldn't find how to duplicate the desktop in the documentation either.
Copy the files by hand?
Create them from scratch (makeini)?

Quote from: StefanZ on 2011.04.18, 22:47:22
Hint: to set additional environment variables for the current user create a file called "environment" in the HOME dir for the current user. My example of C:\HOME\BOLDOS\environment file contents:

DESKTOP=C:\Desktop
USER_INI=C:\HOME\BOLDOS\OS2.INI
SYSTEM_INI=C:\HOME\BOLDOS\OS2SYS.INI
MOZILLA_HOME=C:\HOME\BOLDOS

So that was what the text tried to say as I read environment as a word without quotes or/and as the environment variable in config.sys/rexx, not as a filename without extension.  :(

Quote from: StefanZ on 2011.04.18, 22:47:22
By this, user BOLDOS has i.e. separately stored profile info and files for Firefox browser.

So one can hide the folder to all other users so one can surf the web to look at all those... ehmm.  ;D

Quote from: StefanZ on 2011.04.18, 22:47:22
There is no such thing as dedicated ACLS editor nor there is any GUI application to do that. Moreover (since SESS is only a layer or drivers and a bunch of some basic cmd line utilities), there is no integration of SESS into desktop to speak of. Unfortunately SESS does not seem to be a fully finished product. This means until a) GUI utilities are created and more importantly b) it gets integrated into desktop by Mensys in some future version of eCS, we are stuck with the bunch of utilities we have and manual editing of cfg files :)

A wps-som class for a programming class trying to learn programming! ;)

Quote from: StefanZ on 2011.04.18, 22:47:22
There are also some other minor issues, such as this one:
I was thinking to lessen the rights to vital parts of the system, so that user has only i.e. read and execute rights to vital system directories such as C:\OS2, C:\ecs, C:\MPTN etc. Unfortunately, the desktop seems to require write access to C:\OS2\os2.ini and/or C:\OS2\os2sys.ini (do not now remember to which one), even if you have separate copies stored in HOME dir for the current user. As a result, you are given a warning message by desktop every 1 minute that desktop cannot write access the file C:\OS2\os*.ini. Most probably this can be overcome, unfortunately for me I have not found a way.

Maybe one can specify the specific files that it should have read/write access to?
The documentation does however not tell you how to achieve that, you'll have to do more trial & error first. :(

Quote from: StefanZ on 2011.04.18, 22:47:22
Yes, it seems to be possible to run DOS command line only when logger in as root. I believe this is due to the limitations of SESS subsystem, since it is not able to process the correct APIs, thus if you are logged as any other user than root, SESS will not "allow" to run DOS. If you are logged as root, then I believe you have full system access by default, thus the limitation of SESS not being able to control the correct APIs does not apply and the system will run the DOS cmd line just fine.

Quote from: StefanZ on 2011.04.18, 22:47:22
For the documentation:
it actually exists, in C:\ecs\SYSTEM\SESS\doc. there is a good explanation + some examples. The rest is trial and error :)
Yes, I read it more than once, but apparently grasped only parts of it and <dll> doesn't really tell med if it'll affect all dll's or what some of those things refer to. That was the part where I couldn't tweak the settings fast enough to have a useful system within reasonable time so "trial & error" made me move all vital folders to another drive and reformat the installation partition and install everything without SSES.

I guess that may be the case for others as well, more polish ;)

Quote from: StefanZ on 2011.04.18, 22:47:22
Please let me know your thoughts and further experiences, I would be quite interested to know your progress :)

Stefan
I'll try in a virtual machine the next time so it won't interfere with any of my 3 real computers.

Thank you once again Stefan for your explanations.
//Jan-Erik

lpino

Quote from: StefanZ on 2011.04.18, 22:47:22

For the documentation:
it actually exists, in C:\ecs\SYSTEM\SESS\doc. there is a good explanation + some examples. The rest is trial and error :)

Please let me know your thoughts and further experiences, I would be quite interested to know your progress :)

Stefan

There are a couple of redbooks that could help. They are at:

I hope it helps. This could be a nice GUI native WPS project

Leonardo

Pete

Hi All

A suggestion for duplicating the original Desktop to any User Desktops created: use wps2rexx

1] run wps2rexx on the original Desktop

2] edit the rexx cmd files generated to remove any unwanted Desktop items

3] run the rexx cmd file when booted to a User Desktop

wps2rexx is here http://hobbes.nmsu.edu/download/pub/os2/util/wps/wps2rexx.zip

I use the above technique to recreate selected bits of my Desktop when installing a later version of eCS.

Regards

Pete



jep

Thank you Leaonardo and Pete,

very interesting information you also provide.
Written books and actual scripts to handle the desktop... Great!


  • There are still some white spots (unknowns).
    Do read some of the docs for us and provide a summary here.
  • Anyone care to design a mockup WPS-GUI we could discuss as well?
    A rough sketch would suffice at first.

//Jan-Erik


warpcafe

Hi guys,

well, a GUI mockup?
If you tell me the use cases, then I can do it.
I am not too savvy avout SESS and Security/2 (the technical features it has) but have a basic concept of ACL, multi-user etc.
I am even willing to read the documents and try to understand/install it... ;)

BTW: Anyone of you coming to WSE in Haarlem...?

Cheers,
Thomas
"It is not worth an intelligent man's time to be in the majority.
By definition, there are already enough people to do that"
- G.H. Hardy

abwillis

Anyone using this with SMP enabled?  I had used it with some of the early RCs with SMP enabled and about every other boot or so it would use 50+% of my CPUs.  I don't know if it was a problem with the SMP itself or the fact that it was seeing two CPUs due to hyperthreading (single core, single CPU but 2 CPUs seen with hyperthreading). 

jep

Hello Thomas,
I won't attend WSE this year either, though I would have liked to. Should have decided that already when it was announced, but...


-------------
Security/2 is a multi-user system for OS/2. It provides controlled access to files, drives, drivers and other OS/2 stuff, based on access control list for each user.


A number of predefined logon methods come with Security/2.
They are:
1) VIO & PM logon that both let the user log on at the end of the boot process with a user name and corresponding password before it will allow further operation (continue in VIO mode or boot to desktop).

2) The logon method that start PMSHELL and show a PM logon window is called a multiple PM local logon shell and allow more users to logon and logoff without a restart of the computer.

Only method 2) will be considerd below.

The multiple logon shell load information from %HOME%\environment seem to have to contain a reference to HOME for the user?!

root (Administrator)
Superuser
User 1       
User 2
User ...
User n

The Administrator log on as root and create other accounts.
Admin is the only one to have access to the administration tool, but noone else should have access to it, not even Superusers!
Coordination with UPM should be transparent and possible for all users that e.g. should have network access to use and map network resources

Superusers may have access to all applications but not to system critical files such as config.sys, key-file archives or other users profiles to minimize number of problems that can otherwise arise. Superuser should be able to install and update applications.

Ordinary users may have more or less access to various parts of the system and applications, but should perhaps be reliefed of the burdon to have to tweak over all system settings that affect others. Ordinary users should not see any folder in boot drive except their own user folder where everything they work on should be saved.

All users should have their own desktops, modeled after a current (all of the time or at creation time?) "template" with appropriate rules applied.
Objects that are restricted/unavailable should be hidden or removed from the user to save space in the ini-files.


Problem
Multiple dekstops combined with multiple archives require that C:\OS2\ARCHIVES doesn't get overwritten with the wrong data during bootup!
Only backup the root account or backup to different folders depending on the user that log on, question is how to achieve that technically.

Suggestions
Template information or Defaults should exist to create Superusers and locked down users.
-----------------
//Jan-Erik