Hmmm... If you think about it, all access controls (for a Class G virtual machine) are mandatory by nature. The virtual machine cannot discretionarily circumvent those limits which are mandatorily placed on it by the hypervisor. This would be true for RACF or for any other ESM ... even "none". (No comments from the man from Endicott.)
The concern I hear about DAC -vs- MAC is that discretionary breaks down (eg: in a poorly written DAC application). So we throw MAC at the problem. It's more complicated, but it relieves programmers of the consequences of being careless, lazy, or stupid. We now shift the burden of security from programmers to ... [drum roll] ... auditors, who will establish and monitor the policy behind your MAC. After all, they know best ... *stop* ... I am straying from the topic. Sorry. Try again. The concern I hear about DAC -vs- MAC is that discretionary breaks down (eg: in a poorly written DAC application). For example, a buggy 'mount' command, which must run as "root", leaves open a back door for the hackers to jimmy. The privileges of 'mount' are elevated by the SETUID bit. It then acts with discretion, only doing what it is supposed to do (only mounting things on user request which are allowed). With virtual machines (assuming a strong hypervisor), all resource access is controlled by the hypervisor. (Hey! There's an idea! Call the hypervisor a "control program"!) There is no concept of "discretionary". There is no back door. The privileges of a virtual machine are not elevated on-the-fly. (At least, not for the sake of running user-space applications.) -- R; <>< On Thu, Apr 9, 2009 at 11:20 AM, Aisik Chang <[email protected]> wrote: > GM, listers, > How do I find whether we are using MAC or DAC (Mandatory or Discretionary > Access Control) in VM/RACF ? > > Thanks, > > Ann
