Michael in the Morning
MichaelAM 01000033W7 Marcações:  aixpert powersc compliance dss security aix expert pci 2.379 Visualizações
Last week I have been at a customer working on a security assessment of their AIX setup. This customer was actually doing quite well compared to many I have reviewed. They had a security policy - and it had been recently updated. However, they were not using AIX Security Expert (aixpert) and that slowed down the process of updating their systems to the new/updated security policy.
Because they asked specifically about PCI compliance I did a little more reading (besides the PowerSC Overview). I went to the PCI site and downloaded the PCI_DSS_v2 guidelines.
I discovered that besides having a PCI.xml file (plus supporting scripts) for configuring systems according to the PCI DSS guidelines PowerSC has two components that will help greatly with satisfying PCI_DSS requirements: Trusted Logging for (more) tamper proof logs; Trusted Network Connection and Patch Management to assist OS fix and update maintenance.
MichaelAM 01000033W7 Marcações:  security restrict rbac unix permit aix access control discretionary dac 2.055 Visualizações
This project - Migrating/Moving to RBAC - "no looking back" is going to take "too much" time to organize the story into a single article, so instead - in the spirit of something you can read "in the Morning" with coffee and toast, or a croissant - I am breaking it into smaller pieces. My intent, when the series is finished, is to make a white paper from them. This is my "rather than wait..." approach.< /p>
The first article was RBAC does not replace DAC automatically. Here I shall start introducing is what DAC is - what are we replacing. And from the information here move on towards how it has been used for years, how a program such as sudo attempts to make us less dependent on a complex DAC model, and how DAC serves as the preferred protection model by black hats (as it is so easy to break! ;)
MichaelAM 01000033W7 Marcações:  euid rwx role control permissionns ruid discretionary access dac rbac based security 2.263 Visualizações
Role Based Access Controls: RBAC does not replace DAC automaticallyRBAC is a mechanism for Access Control and that is the key to what is wrong
with most implementations using RBAC as an access control. Huh? Isn't RBAC meant to be
the next greatest thing in Access Control? What goes?
Yes. RBAC is meant to be the next step in Access Control - but it's effect as THE controlling mechanism is minimal as long as DAC is still active. DAC?? Discretionary Access Control.
Discretionalry Access Control, also known as DAC, is the traditional access control mechanism for UNIX and Linix based systems (so also OS/X and deep down NT-based systems). Actually, any access system where the owner of a "object" (file, device, directory, or any other names for "special" something) can modify the access permissions - at whim - is discretionary.
Focusing on UNIX/Linux based permissions there are 9 (nine) permission bits we need to
On UNIX an identity at any given time is: euid,set of group ids. Normally the euid == ruid i.e. effective uid == real uid - where ruid is meant to be a login id. Using DAC mechanisms the OS looks at the active identity (try the command id to see your current identity) and the object permission sets. If the "owner id" and euid match, then those bits determine the current access. If the owner IDs do not match then the system looks at the "group ID" of the object and compares that with the set of active group ids and if there is a match then the group ID permissions are used to determine access control. If neither "owner" nor "group" IDs have a match then the "other" IDs determine access to the object (e.g., file, directory, device). This is where/why RBAC generally "fails". RBAC has been implemented as an additional access control mechanism - rather than as a replacement.
In other words, RBAC, by default, is always looking back - providing access the way it has always been done. The behavior is as if the OS is always looking back - determining access based on DAC first, and RBAC as a second thought.
That is all for today - next article I shall discuss how DAC is used to setup selective
access control - user DAC being whatever the owner wants for themself - and other access
for everyone (non-selective) else. And I'll also explain the command