home-metier    Home Sample-Unix     Hypo Notpd-Webtg     Hypo Dnote     Dnote - Notpd    Dnote - Mailbx     Dnote - Webtg     BI & business
Notepad    Webthing    top  bottom

Hypothetical implementations Unix,
middleware & Business

Security opertating Design
Management of two hypothetische applications on Linux.
  1. Suppose our hypothetical application is named "notepad" and exist of one(1) file notepad.
  2. Suppose our hypothetical application is named "webthing" consisting of multiple files with more advanced fucntionality

The sample is covering the basic principles of implementing applications (middleware) on Linux. Linux is just a Unix variant, these samples will apply to all Unix variants.


Hypothetical Notepad


Establishment NOTEPAD V1


The use of the root-key is to be avoided installing NOTEPAD. The purpose of the root-key is to use it only at the initial installing of Linux (the operating system) on the machine.
We are needing a service account (keys) and related group. Propose:
The executable NOTEPAD will be placed in map dedicated to NOTEPAD. Within the Linux community a map located below "/opt" is a common practice.
Schematic it will look like:
map /file D/F Owner Group Public
/opt/notepad D INSTNOTE: RWX RUNNOTE: R-X ---
/opt/notepad/bin D INSTNOTE: RWX RUNNOTE: R-X ---
/opt/notepad/bin/notepad F INSTNOTE: RWX RUNNOTE: R-X ---


See fileattributes explanantion and links
Short notation: INSTNOTE:RUNNOTE RWX R-X ---
The result is: all customers with their account that is member of the group RUNNOTE, are allowed to start the executable NOTEPAD. Only the technical owner INSTNOTE is capable to manage the NOTEPAD executable.

Shortcomings of NOTEPAD V1




Establishment NOTEPAD V2


Improvement log-file:
Within the Linux community a map located below "/var/local/log" is a common practice storing logfiles.

Schematic it will look like:
map /file D/F Owner Group Public
/var/local/log/NOTEPAD D INSTNOTE: RWX RUNNOTE: RWX --T

The T is the sticky bit set on the directory. It will add required security to shared directories. See fileattributes explanantion and links

At this point every customer having the right of starting NOTEPAD wil be able to create a log file with his own personal credentials. Nobody else, as the customer owning the logfile, or the service account INSTNOTE, are able to view or remove that particular log-file


Let two different customers "A" and "B" starting NOTEPAD and create a log file. The log file name will get the same name as their account (.log)
Schematic it will look like:

map /file D/F Owner Group Public
/var/local/log/NOTEPAD D INSTNOTE: RWX RUNNOTE: RWX --T
/var/local/log/NOTEPAD/A.log F A: RWX BR10001: R-X ---
/var/local/log/NOTEPAD/B.log F B: RWX BR10002: R-X ---


Notice 1: BR10001 and BR10002 are the primary groups that are defined for the customers accounts A ,B .
Notice 2: Customers with account A and B are able to change their own file access rights to any setting they like. The reason is they are the technical owner of their files. A standard default secured setting (umask 027) is resulting in the above situation owner RWX group R-X Public ---. See DAC - File Directory access


Improvement administrator:
To do the daily administrations have executed by an other account as the personal key the "SuDo" commando (SuDo=SwitchUser/DoIt) is available. The administrator does a login with his personal key. He uses the "sudo" command switching conext. It is the same like "RUNAS" in Windows or "SURROGATE" in Mainframe.

The account INSTNOTE should not be able to use sshd, the direct login to a terminal. This needs to be protected, implementation can be done by the nosshd group.
As an alternative other tools like Boks are optional.

See nosshd explanantion and links
Note: Adding a group in the autorization profile will have the effect in limiting functionality. The normal expectation is adding groups will add fucntionality.

Improvement profile:
Every new process that is started wil get an environment as defined by the system (OS) installation. At user level or at appliaction level (NOTEPAD) additions or changes on this default are required. How is this solved?
Every user is able to define in his own directory, "home" to be find as ~, define a ".profile" file. This is a personal script.
Contents may be like:
#!/usr/bin/ksh
Echo "profile for myself …"
export PATH=/opt/notepad/bin:$PATH
return



Usual also a profile file with the name of: "/etc/.profile" is executed first starting every process.
Contents may be like:

. ${_LOCAL:-/usr/local}/etc/profile



In this way generic to be reused settings at application level is to be administrated.
Every application (tool/middleware - business) is able to store at a predefined location (as example: "/usr/local/etc") store a "profile." script.
In case of the NOTEPAD application we would store a script: "/usr/local/etc/profile.NOTEPAD"
Contents:
#!/usr/bin/ksh
Echo "profile for NOTEPAD users …"
export PATH=/opt/notepad/bin:$PATH
return


In this way every user is able to start notepad by typing the "commando NOTEPAD".

Shortcomings & Improvements NOTEPAD V2

The account INSTNOTE has two goals: The mix up of different goals introduces the risk of harming the installation of NOTEPAD while just working on the logfiles. The installation key INSTNOTE should be very restricted not able to run processes having unmanaged (audited logged) access.

Improvement
Create an account BEHNOTE in the only goal of managing the loggings. The cleaning of logfiles can be scheduled by using cron/crontab.
The more secure way is requiring an other dedicated service account.
Schematic the change will look like:
map /file D/F Owner Group Public
/var/local/log/NOTEPAD D BEHNOTE: RWX RUNNOTE: RWX --T

Profile scripts - Shortcomings

The process of profile scripts as described only is fucntioning with the classic terminal usage.
Every other way like using a CRON scriptted startup or dedecicated processes port-port communication not using ssh (terminal) are bypassing this process.

The same logic has to be implemented in other scripts or must be a parameter in te applications start script.



Notepad    Webthing    top  bottom

Hypothetical WebThing

Webthing V1

Nu tijd voor een iets complexere hypothetische applicatie: een webserver-achtig ding, genaamd WebDing. WebDing is een daemon proces dat luistert op een TCP poort, opdrachten ontvangt, subprocessen opstart om die opdrachten uit te voeren. WebDing heeft administrator interface. Om WebDing efficiënt te laten werken heeft deze een pool van subprocessen tot zijn beschikking om de opdrachten uit te voeren.
WebDing draait samen met andere complexe zaken op die server. Dus hergebruik van accounts is een overweging.
We hebben nodig een installatie account, een beheer account voor logs, schoning, etc. een deamon account en een admin account
  1. INSTWD, installatie account
  2. BEHWD, beheer account
  3. RUNWD, deamon account waarmee de spawner uitgevoerd wordt
  4. EXECWD, account waarmee de subprocessen worden uitgevoerd
  5. ADMWD, admin account
WebDing bestaat uit een aantal executables :
  1. WebDing, de webserver zelf
  2. WebDingSpawner, waarmee subprocessen worden opgestart
  3. WebDingRunexec, het subproces
  4. WebDingAdmin, de administrator tool
Dan richten we het als volgt in:
map /file D/F Owner Group Public
/opt/WebDing D INSTWD: RWX RUNWD: R-X ---
/opt/WebDing/bin D INSTWD: RWX RUNWD: R-X ---
/opt/WebDing/bin/WebDing F INSTWD: RWX RUNWD: R-X ---
/opt/WebDing/bin/WebDingSpawner F root: RWS RUNWD: R-X ---
/opt/WebDing/bin/WebDingRunExec F INSTWD: RWX RUNWD: R-X ---
/opt/WebDing/bin/WebDingAdmin F INSTWD: RWX RUNWD: R-X ---
/var/local/log/WebDing D BEHWD: RWX RUNWD: RWX. --T
/usr/local/WebDing D ADMWD: RWX RUNWD: R-X ---

Notice 1: root is het enige account dat processen mag spawnen/forken onder een ander account. Het ownership moet apart gezet worden. Dit kan niet in een script. Dit moet door root zelf gedaan worden.
Notice 2: WebDing moet WebDingSpawner opstarten, dat onder root moet draaien. Daarvoor moet het set-UID bit gezet zijn.
Notice 3: RUNWD is een group, maar de naam wordt ook gebruikt voor een account. Accounts INSTWD, BEHWD, RUNWD, EXECWD en ADMWD moeten allemaal lid zijn van group RUNWD.
Notice 4: We hebben dus 6 accounts in gebruik voor 4 executables.
De deamon WebDing starten we onder het account RUNWD.
Nu hebben we geregeld dat WebDing niet zijn eigen installatie kan aanpassen, maar wel subprocessen mag aftrappen, en kan loggen.
Een zwak punt in deze inrichting is dat WebDing van iedereen opdrachten aanneemt op zijn listening port. De oplossing valt buiten de scope van dit stuk. Wel merken we op dat WebDing niets buiten zijn eigen installatie kan doen.
Account WebDingRunExec draait executable WebDingRunExec. Dit account heeft ook geen rechten buiten de installatie. Dus als dit account zaken moet regelen voor een klant, dan moeten daar rechten voor toegewezen worden. Dit is dus een NPA voor middleware waar ook groepen van klanten aan komen te hangen op een machine.
Account ADMWD zal alleen opengezet hoeven te worden als er een verzoek om administratie geregistreerd en toegewezen is. Een mogelijkheid is dat een beheerder aanlogt aan de machine met sudo/BOKS wisselt naar ADMWD. Hij kan nu het programma WebDingAdmin starten, en configuratie settings aanpassen, zoals listening port, SSL , etc. afhankelijk van de functionaliteit die geboden wordt. Dit programma heeft tot toegang tot de map met configuratie settings /usr/local/WebDing. Merk op dat de administrator in de huidige opzet ook parameters met de hand kan aanpassen.
Web-applicaties vs. klantapplicaties



Webthing to Business

Deze webapplicatie kan nog helemaal niks doen want er is geen klantapplicatie aanwezig. Het is tot weinig meer in staat dan "Hello World" o.i.d. in een pagina te tonen. We constateren dat de webapplicatie feitelijk niet bestaat, en op dit moments niets meer is dan een stuk infrastructuur. Op deze infrastructuur kunnen klantapplicaties landen. Daarvoor moeten een paar dingen geregeld worden. Er is nodig een administratie van klantapplicaties, c.q. klantomgevingen. Voor een klantomgeving worden twee soorten gegeven onderkend:
1. business logica
2. business data / bedrijfsgegevens
De business logica zit in een DTAP cyclus met overdrachten.
De bedrijfsgegevens worden strikt gescheiden gehouden.
Voor die klantapplicatie is nodig functionaliteit om een gebruiker te identificeren.
Het inrichten van een klantomgeving op de hypothetische webserver-achtige ding
De klant komt aan met een stuk bedrijfslogica. Dit kan zijn een webapplicatie, plaatjes documenten etc. En de klant komt met connectiegegevens naar databases met bedrijfsgegevens of met vers gegenereerde rapporten.
We hebben een APPL tak van storage voor de bedrijfslogica.
We hebben een DATA tak van storage voor de bedrijfsdata.
En nu inrichten …




Notepad    Webthing    top  bottom
home-metier    Home Sample-Unix     Hypo Notpd-Webtg     Hypo Dnote     Dnote - Notpd    Dnote - Mailbx     Dnote - Webtg     BI & business

© 2012 J.A.Karman (02 may 2012 - PK )