Tuesday Jun 11, 2013

Monitoring per Zone Filesystem activity

Solaris 11 added a new at fsstat(1M) monitoring command that provided the ability to view filesystem activity at the VFS layer (ie filesystem independent).  This command was available in Solaris 11 Express and the OpenSolaris releases as well.

Here is a simple example of looking at 5 one second intervals of writes to all ZFS filesystems

$ fsstat zfs 1 5
 new  name   name  attr  attr lookup rddir  read read  write write
 file remov  chng   get   set    ops   ops   ops bytes   ops bytes
3.79M 3.39M 1.77M 1003M 1.24M  6.16G 49.9M  425M 2.01T  160M  467G zfs
    0     0     0    55     0    416     6     0     0 42.7K 21.3M zfs
    0     0     0     4     0     18     0     0     0 44.0K 22.0M zfs
    0     0     0     5     0     28     0     0     0 44.0K 22.0M zfs
    0     0     0     4     0     18     0     0     0 40.3K 20.1M zfs
    0     0     0   260     0  1.08K     0     0     0 36.7K 18.4M zfs

In Solaris 11.1 support was added for per Zone and aggregated information so now we can very quickly determine which zone it is that is contributing to the operations, for example:

$ fsstat -Z zfs 1 5
 new  name   name  attr  attr lookup rddir  read read  write write
 file remov  chng   get   set    ops   ops   ops bytes   ops bytes
3.79M 3.39M 1.77M  998M 1.24M  6.13G 49.4M  424M 2.01T  159M  467G zfs:global
   62    55    39 4.85M   250  33.2M  575K  157K  138M 8.66K 11.6M zfs:s10u9
  114    91    33  115K   362   429K 3.80K  133K  180M  116K 87.2M zfs:ltz
    0     0     0 1.06K     0  3.44K    14    71 12.9K     6 1.43K zfs:global
    0     0     0     2     0      8     0     1    1K     0     0 zfs:s10u9
    0     0     0     0     0      0     0     0     0 41.7K 20.9M zfs:ltz
    0     0     0     4     0     18     0     0     0     0     0 zfs:global
    0     0     0    51     0    398     6     0     0     0     0 zfs:s10u9
    0     0     0     0     0      0     0     0     0 42.6K 21.3M zfs:ltz
    0     0     0     4     0     18     0     0     0     0     0 zfs:global
    0     0     0     0     0      0     0     0     0     0     0 zfs:s10u9
    0     0     0     0     0      0     0     0     0 44.0K 22.0M zfs:ltz
    0     0     0     5     0     28     0     0     0     0     0 zfs:global
    0     0     0     0     0      0     0     0     0     0     0 zfs:s10u9
    0     0     0     0     0      0     0     0     0 43.9K 22.0M zfs:ltz
    0     0     0     4     0     18     0     0     0     0     0 zfs:global
    0     0     0     0     0      0     0     0     0     0     0 zfs:s10u9
    0     0     0     0     0      0     0     0     0 38.9K 19.5M zfs:ltz
 

Thursday Apr 04, 2013

mdb ::if

The Solaris mdb(1) live and post-mortem debugger gained a really powerful new dcmd called ::if in the Solaris 11.1 release.

As a very quick example of how powerful it can be here is a short one liner to find all the processes that are running with their real and effective uid

> ::ptree | ::if proc_t p_cred->cr_ruid <> p_cred->cr_uid | ::print proc_t p_user.u_comm

Or a similar one to find out all the priv aware processes, this time showing some output:

> ::ptree | ::if proc_t p_cred->cr_priv.crpriv_flags & 0x0002 | ::print proc_t p_user.u_comm
p_user.u_comm = [ "su" ]
p_user.u_comm = [ "nfs4cbd" ]
p_user.u_comm = [ "lockd" ]
p_user.u_comm = [ "nfsmapid" ]
p_user.u_comm = [ "statd" ]
p_user.u_comm = [ "nfs4cbd" ]
...

The new ::if is very powerful and can do much more advanced things, like substring comparison, than my simple examples, but I choose examples that are useful to me and relevant to security.

Wednesday Feb 20, 2013

Generating a crypt_sha256 hash from the CLI

When doing a completely hands off Solaris installation the System Configuration profile needs to contain the hash for the root password, and the optional inital non root user.

Unfortunately Solaris doesn't currently provide a simple to use command for generating these hashes, but with a very simple bit of Python you can easily create them:

#!/usr/bin/python

import crypt, getpass, os, binascii

if __name__ == "__main__":
    cleartext = getpass.getpass()
    salt = '$5$' + binascii.b2a_base64(os.urandom(8)).rstrip() + '$'

    print crypt.crypt(cleartext, salt)



        
    

Tuesday Feb 19, 2013

Linux YAMA Security equivalents in Solaris

The Linux YAMA Loadable Security Module (LSM) provides a small number of protections over and above standard DAC (Discretionary Access Controls).  These can be roughly mapped over to Solaris as follows:

YAMA_HARDLINKS: 

This protects against creation of hardlinks to files that a user does not have access to.  For some strange reason POSIX still requires this behaviour.

Closest Solaris equivalent is removing the file_link_any basic privilege from a process/service/user, the description of file_link_any is:

    Allows a process to create hardlinks to files owned by a uid different from the process' effective uid.

YAMA_PTRACE:

This YAMA protection is designed to protect process running as the same uid from being able to attach to each other and trace them using PTRACE.

For mapping this to Solaris I'd recommend removal of two of the proc basic privileges, this will actually exceed the protection that YAMA_PTRACE gives:

proc_session
    Allows a process to send signals or trace processes outside its session.
proc_info
    Allows a process to examine the status of processes other than those it can send signals to.  Processes which cannot be examined cannot be seen in /proc and appear not to exist.

YAMA_SYMLINKS:

The description of the Linux YAMA LSM that I looked at as one more protection YAMA_SYMLINKS, there is no Solaris equivalent to this one that I can find.  It is intended to protect against race conditions on symlinks in world-writable directories (eg /tmp).  This is a nice protection but we don't have an equivalent of it in Solaris at this time but I think it could be implemented as another basic privilege.

Reminder on Solaris Basic Privileges

As a reminder basic privileges in Solaris are those which processes normally have because they were not normally considered to be security violations in the UNIX process model.  A basic privilege can be removed from an SMF service in its method_credential section, from a users login session (usermod -K defaultpriv=basic,!file_link_any <username>).  So there is no need to patch/rebuild/update the Solaris kernel to be able to take advantage of these.  In fact you can even change a running process using ppriv(1).

Monday Feb 11, 2013

Serial Console with VirtualBox on Solaris host

First make sure you have nc(1) available it is in the pkg:/network/netcat package.

Then configure COM1 serial port in the VM settings as a pipe.  Tell VirtualBox the name you want for the pipe and get it to create it.

You can also set up the serial port from the CLI using the VBoxManage command, here my VM is called "Solaris 11.1 Text Only".

$ VBoxManage modifyvm "Solaris 11.1 Text Only" --uart1 0x3F8 4 --uartmode1 server /tmp/solaris-11.1-console.pipe

 

Start up the VM and in a terminal window run nc and the ttya output of the VM will appear in the terminal window.

$ nc -U /tmp/solaris-11.1-console.pipe
SunOS Release 5.11 Version 11.1 64-bit
Copyright (c) 1983, 2012, Oracle and/or its affiliates. All rights reserved.


Thursday Jan 24, 2013

Compliance reporting with SCAP

In Solaris 11.1 we added the early stages of our (security) Compliance framework.  We have (like some other OS vendors) selected to use the SCAP (Security Content Automation Protocol) standard from NIST.  There are a number of different parts to SCAP but for Compliance reporting one of the important parts is the OVAL (Open Vulnerability Assesment Language) standard.  This is what allows us to write a checkable security policy and verify it against running systems.

The Solaris 11.1 repository includes the OpenSCAP tool that allows us to generate reports written in the OVAL language (as well as other things but I'm only focusing on OVAL for now).

OVAL is expressed in XML with a number of generic and OS/application specific schema.  Over time we expect to deliver various sample security policies with Solaris to help customers with Compliance reporting in various industries (eg, PCI-DSS, DISA-STIG, HIPAA).

The XML in the OVAL langauge is passed to the OpenSCAP tool for evaluation, it produces either a simple text report of which checks passed and which failed or an XML results file and an optional HTML rendered report.

Lets look at a simple example of an policy written in OVAL.  This contains just one check, that we have configured the FTP server on Solaris to display a banner.  We do this in Solaris 11 by updating /etc/proftpd.conf to add the "DisplayConnect /etc/issue" line - which is not there by default.   So in a default Solaris 11.1 system we should get a "fail" from this policy.

The OVAL for this check was generated by a tool called "Enhanced SCAP Editor (eSCAPe)" which is not included in Solaris.  It could well have been hand edited in your text editor of choice. In a later blog posting I'll attempt to explain more of the OVAL language and give some more examples, including some Solaris specific ones but for now here is the raw XML:

<?xml version="1.0" encoding="UTF-8"?>
<oval_definitions xmlns="http://oval.mitre.org/XMLSchema/oval-definitions-5" 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
xmlns:oval="http://oval.mitre.org/XMLSchema/oval-common-5" 
xmlns:oval-def="http://oval.mitre.org/XMLSchema/oval-definitions-5" 
xmlns:independent-def="http://oval.mitre.org/XMLSchema/oval-definitions-5#independent" 
xsi:schemaLocation="http://oval.mitre.org/XMLSchema/oval-definitions-5 
   oval-definitions-schema.xsd http://oval.mitre.org/XMLSchema/oval-definitions-5#independent 
   independent-definitions-schema.xsd http://oval.mitre.org/XMLSchema/oval-common-5 oval-common-schema.xsd">

  <generator>
    <oval:product_name>Enhanced SCAP Editor</oval:product_name>
    <oval:product_version>0.0.11</oval:product_version>
    <oval:schema_version>5.8</oval:schema_version>
    <oval:timestamp>2012-10-11T10:33:25</oval:timestamp>
  </generator>
  <!--generated.oval.base.identifier=com.oracle.solaris11-->
  <definitions>
    <definition id="oval:com.oracle.solaris11:def:840" version="1" class="compliance">
      <metadata>
        <title>Enable a Warning Banner for the FTP Service</title>
        <affected family="unix">
          <platform>Oracle Solaris 11</platform>
        </affected>
        <description>/etc/proftpd.conf contains "DisplayConnect /etc/issue"</description>
      </metadata>
      <criteria operator="AND" negate="false" comment="Single test">
        <criterion comment="/etc/proftpd.conf contains &quot;DisplayConnect /etc/issue&quot;" 
          test_ref="oval:com.oracle.solaris11:tst:8400" negate="false"/>
      </criteria>
    </definition>
  </definitions>
  <tests>
    <textfilecontent54_test 
        xmlns="http://oval.mitre.org/XMLSchema/oval-definitions-5#independent" 
        id="oval:com.oracle.solaris11:tst:8400" version="1" check="all" 
        comment="/etc/proftpd.conf contains &quot;DisplayConnect /etc/issue&quot;" 
        check_existence="all_exist">
      <object object_ref="oval:com.oracle.solaris11:obj:8400"/>
    </textfilecontent54_test>
  </tests>
  <objects>
    <textfilecontent54_object 
        xmlns="http://oval.mitre.org/XMLSchema/oval-definitions-5#independent" 
        id="oval:com.oracle.solaris11:obj:8400" version="1" 
        comment="/etc/proftpd.conf contains &quot;DisplayConnect /etc/issue&quot;">
      <path datatype="string" operation="equals">/etc</path>
      <filename datatype="string" operation="equals">proftpd.conf</filename>
      <pattern datatype="string" 
         operation="pattern match">^DisplayConnect\s/etc/issue\s$</pattern>
      <instance datatype="int" operation="greater than or equal">1</instance>
    </textfilecontent54_object>
  </objects>
</oval_definitions>

We can evaluate this policy on a given host by using OpenSCAP like this:

$ oscap oval eval ftp-banner.xml 
Definition oval:com.oracle.solaris11:def:840: false
Evaluation done.

As you can see we got the expected failure of the test, but that output isn't very useful, lets instead generate some html output:

$ oscap oval eval --results results.xml --report report.html ftp-banner.xml
Definition oval:com.oracle.solaris11:def:840: false
Evaluation done.
OVAL Results are exported correctly.

Now we have a report.html file which looks like a bit like this:

OVAL Results Generator Information
Schema Version Product Name Product Version Date Time
5.8  cpe:/a:open-scap:oscap 
2013-01-24 14:18:55 
OVAL Definition Generator Information
Schema Version Product Name Product Version Date Time
5.8  Enhanced SCAP Editor  0.0.11  2012-10-11 10:33:25 

System Information
Host Name braveheart 
Operating System SunOS 
Operating System Version 11.1 
Architecture i86pc 
Interfaces
Interface Name net0 
IP Address 192.168.1.1 
MAC Address aa:bb:cc:dd:ee:ff 
OVAL System Characteristics Generator Information
Schema Version Product Name Product Version Date Time
5.8  cpe:/a:open-scap:oscap 
2013-01-24 14:18:55 
Oval Definition Results



 True  



 False  



 Error  



 Unknown  



 Not Applicable  



 Not Evaluated  
OVAL ID Result Class Reference ID Title
oval:com.oracle.solaris11:def:841 true compliance
Enable a Warning Banner for the SSH Service 
oval:com.oracle.solaris11:def:840 false compliance
Enable a Warning Banner for the FTP Service 

As you probably noticed write away the report doesn't match the OVAL I gave above because the report is actually from a very slightly larger OVAL file which checks the banner exists for both SSH and FTP.  I did this purely to cut down on the amount of raw XML above but also so the report would show both a success and failure case.


Tuesday Jan 08, 2013

Solaris 11.1 FIPS 140-2 Evaluation status

Solaris 11.1 has just recently been granted CAVP certificates by NIST, this is the first formal step in getting a FIPS 140-2 certification.  It will be some months yet before we expect to see the results of the CMVP (FIPS 140-2) evaluation.  There are multiple certificates for each algorithm to cover the cases of SPARC and x86 with and with out hardware acceleration from the CPU.

References:
AES 2310, 2309, 2308
3DES 1457, 1456, 1455
DSA 727, 726
RSA 1193, 1192, 1191
ECDSA 375, 375, 374
SHS (SHA1, 224, 256, 384, 512) 1994, 1993, 1992
RNG 1153, 1152, 1151, 1150
HMAC 1424, 1423, 1422




Monday Dec 03, 2012

Using Solaris pkg to list all setuid or setgid programs

$ pkg contents -a mode=4??? -a mode=2??? -t file -o pkg.name,path,mode

We can also add a package name on the end to restrict it to just that single package eg:

 
  

$ pkg contents -a mode=4??? -a mode=2??? -t file -o pkg.name,path,mode core-os

PKG.NAME       PATH                   MODE
system/core-os usr/bin/amd64/newtask  4555
system/core-os usr/bin/amd64/uptime   4555
system/core-os usr/bin/at             4755
system/core-os usr/bin/atq            4755
system/core-os usr/bin/atrm           4755
system/core-os usr/bin/crontab        4555
system/core-os usr/bin/mail           2511
system/core-os usr/bin/mailx          2511
system/core-os usr/bin/newgrp         4755
system/core-os usr/bin/pfedit         4755
system/core-os usr/bin/su             4555
system/core-os usr/bin/tip            4511
system/core-os usr/bin/write          2555
system/core-os usr/lib/utmp_update    4555
system/core-os usr/sbin/amd64/prtconf 2555
system/core-os usr/sbin/amd64/swap    2555
system/core-os usr/sbin/amd64/sysdef  2555
system/core-os usr/sbin/amd64/whodo   4555
system/core-os usr/sbin/prtdiag       2755
system/core-os usr/sbin/quota         4555
system/core-os usr/sbin/wall          2555


Tuesday Oct 30, 2012

New ZFS Encryption features in Solaris 11.1

Solaris 11.1 brings a few small but significant improvements to ZFS dataset encryption.  There is a new readonly property 'keychangedate' that shows that date and time of the last wrapping key change (basically the last time 'zfs key -c' was run on the dataset), this is similar to the 'rekeydate' property that shows the last time we added a new data encryption key.

$ zfs get creation,keychangedate,rekeydate rpool/export/home/bob
NAME                   PROPERTY       VALUE                  SOURCE
rpool/export/home/bob  creation       Mon Mar 21 11:05 2011  -
rpool/export/home/bob  keychangedate  Fri Oct 26 11:50 2012  local
rpool/export/home/bob  rekeydate      Tue Oct 30  9:53 2012  local

The above example shows that we have changed both the wrapping key and added new data encryption keys since the filesystem was initially created.  If we haven't changed a wrapping key then it will be the same as the creation date.  It should be obvious but for filesystems that were created prior to Solaris 11.1 we don't have this data so it will be displayed as '-' instead.

Another change that I made was to relax the restriction that the size of the wrapping key needed to match the size of the data encryption key (ie the size given in the encryption property).  In Solaris 11 Express and Solaris 11 if you set encryption=aes-256-ccm we required that the wrapping key be 256 bits in length.  This restriction was unnecessary and made it impossible to select encryption property values with key lengths 128 and 192 when the wrapping key was stored in the Oracle Key Manager.  This is because currently the Oracle Key Manager stores AES 256 bit keys only.  Now with Solaris 11.1 this restriciton has been removed.

There is still one case were the wrapping key size and data encryption key size will always match and that is where they keysource property sets the format to be 'passphrase', since this is a key generated internally to libzfs and to preseve compatibility on upgrade from older releases the code will always generate a wrapping key (using PKCS#5 PBKDF2 as before) that matches the key length size of the encryption property.

The pam_zfs_key module has been updated so that it allows you to specify encryption=off.

There were also some bugs fixed including not attempting to load keys for datasets that are delegated to zones and some other fixes to error paths to ensure that we could support Zones On Shared Storage where all the datasets in the ZFS pool were encrypted that I discussed in my previous blog entry.

If there are features you would like to see for ZFS encryption please let me know (direct email or comments on this blog are fine, or if you have a support contract having your support rep log an enhancement request).




  

  


Monday Oct 29, 2012

Solaris 11.1: Encrypted Immutable Zones on (ZFS) Shared Storage

Solaris 11 brought both ZFS encryption and the Immutable Zones feature and I've talked about the combination in the past.  Solaris 11.1 adds a fully supported method of storing zones in their own ZFS using shared storage so lets update things a little and put all three parts together.

When using an iSCSI (or other supported shared storage target) for a Zone we can either let the Zones framework setup the ZFS pool or we can do it manually before hand and tell the Zones framework to use the one we made earlier.  To enable encryption we have to take the second path so that we can setup the pool with encryption before we start to install the zones on it.

We start by configuring the zone and specifying an rootzpool resource:

# zonecfg -z eizoss
Use 'create' to begin configuring a new zone.
zonecfg:eizoss> create
create: Using system default template 'SYSdefault'
zonecfg:eizoss> set zonepath=/zones/eizoss
zonecfg:eizoss> set file-mac-profile=fixed-configuration
zonecfg:eizoss> add rootzpool
zonecfg:eizoss:rootzpool> add storage \
  iscsi://my7120.example.com/luname.naa.600144f09acaacd20000508e64a70001
zonecfg:eizoss:rootzpool> end
zonecfg:eizoss> verify
zonecfg:eizoss> commit
zonecfg:eizoss> 

Now lets create the pool and specify encryption:

# suriadm map \
   iscsi://my7120.example.com/luname.naa.600144f09acaacd20000508e64a70001
PROPERTY	VALUE
mapped-dev	/dev/dsk/c10t600144F09ACAACD20000508E64A70001d0
# echo "zfscrypto" > /zones/p
# zpool create -O encryption=on -O keysource=passphrase,file:///zones/p eizoss \
   /dev/dsk/c10t600144F09ACAACD20000508E64A70001d0
# zpool export eizoss

Note that the keysource example above is just for this example, realistically you should probably use an Oracle Key Manager or some other better keystorage, but that isn't the purpose of this example.  Note however that it does need to be one of file:// https:// pkcs11: and not prompt for the key location.  Also note that we exported the newly created pool.  The name we used here doesn't actually mater because it will get set properly on import anyway. So lets go ahead and do our install:

zoneadm -z eizoss install -x force-zpool-import
Configured zone storage resource(s) from:
    iscsi://my7120.example.com/luname.naa.600144f09acaacd20000508e64a70001
Imported zone zpool: eizoss_rpool
Progress being logged to /var/log/zones/zoneadm.20121029T115231Z.eizoss.install
    Image: Preparing at /zones/eizoss/root.

 AI Manifest: /tmp/manifest.xml.ujaq54
  SC Profile: /usr/share/auto_install/sc_profiles/enable_sci.xml
    Zonename: eizoss
Installation: Starting ...

              Creating IPS image
Startup linked: 1/1 done
              Installing packages from:
                  solaris
                      origin:  http://pkg.oracle.com/solaris/release/
              Please review the licenses for the following packages post-install:
                consolidation/osnet/osnet-incorporation  (automatically accepted,
                                                          not displayed)
              Package licenses may be viewed using the command:
                pkg info --license <pkg_fmri>
DOWNLOAD                                PKGS         FILES    XFER (MB)   SPEED
Completed                            187/187   33575/33575  227.0/227.0  384k/s

PHASE                                          ITEMS
Installing new actions                   47449/47449
Updating package state database                 Done 
Updating image state                            Done 
Creating fast lookup database                   Done 
Installation: Succeeded

         Note: Man pages can be obtained by installing pkg:/system/manual

 done.

        Done: Installation completed in 929.606 seconds.


  Next Steps: Boot the zone, then log into the zone console (zlogin -C)

              to complete the configuration process.

Log saved in non-global zone as /zones/eizoss/root/var/log/zones/zoneadm.20121029T115231Z.eizoss.install

That was really all we had to do, when the install is done boot it up as normal.

The zone administrator has no direct access to the ZFS wrapping keys used for the encrypted pool zone is stored on.  Due to how inheritance works in ZFS he can still create new encrypted datasets that use those wrapping keys (without them ever being inside a process in the zone) or he can create encrypted datasets inside the zone that use keys of his own choosing, the output below shows the two cases:

rpool is inheriting the key material from the global zone (note we can see the value of the keysource property but we don't use it inside the zone nor does that path need to be (or is) accessible inside the zone). Whereas rpool/export/home/bob has set keysource locally.

 
  

# zfs get encryption,keysource rpool rpool/export/home/bob NAME PROPERTY VALUE SOURCE rpool encryption on inherited from $globalzone rpool keysource passphrase,file:///zones/p inherited from $globalzone rpool/export/home/bob encryption on local rpool/export/home/bob keysource passphrase,prompt local

 

 

Thursday Sep 13, 2012

To encryption=on or encryption=off a simple ZFS Crypto demo

I've just been asked twice this week how I would demonstrate ZFS encryption really is encrypting the data on disk.  It needs to be really simple and the target isn't forensics or cryptanalysis just a quick demo to show the before and after.

I usually do this small demo using a pool based on files so I can run strings(1) on the "disks" that make up the pool. The demo will work with real disks too but it will take a lot longer (how much longer depends on the size of your disks).  The file hamlet.txt is this one from gutenberg.org

# mkfile 64m /tmp/pool1_file
# zpool create clear_pool /tmp/pool1_file
# cp hamlet.txt /clear_pool
# grep -i hamlet /clear_pool/hamlet.txt | wc -l

Note the number of times hamlet appears

# zpool export clear_pool
# strings /tmp/pool1_file | grep -i hamlet | wc -l

Note the number of times hamlet appears on disk - it is 2 more because the file is called hamlet.txt and file names are in the clear as well and we keep at least two copies of metadata.

Now lets encrypt the file systems in the pool.
Note you MUST use a new pool file don't reuse the one from above.

# mkfile 64m /tmp/pool2_file
# zpool create -O encryption=on enc_pool /tmp/pool2_file
Enter passphrase for 'enc_pool': 
Enter again: 
# cp hamlet.txt /enc_pool
# grep -i hamlet /enc_pool/hamlet.txt | wc -l

Note the number of times hamlet appears is the same as before

# zpool export enc_pool
# strings /tmp/pool2_file | grep -i hamlet | wc -l

Note the word hamlet doesn't appear at all!

As a said above this isn't indended as "proof" that ZFS does encryption properly just as a quick to do demo.

Wednesday Jul 04, 2012

Delegation of Solaris Zone Administration

In Solaris 11 'Zone Delegation' is a built in feature. The Zones system now uses fine grained RBAC authorisations to allow delegation of management of distinct zones, rather than all zones which is what the 'Zone Management' RBAC profile did in Solaris 10.

The data for this can be stored with the Zone or you could also create RBAC profiles (that can even be stored in NIS or LDAP) for granting access to specific lists of Zones to administrators.

For example lets say we have zones named zoneA through zoneF and we have three admins alice, bob, carl.  We want to grant a subset of the zone management to each of them.

We could do that either by adding the admin resource to the appropriate zones via zonecfg(1M) or we could do something like this with RBAC data directly:

First lets look at an example of storing the data with the zone.

# zonecfg -z zoneA
zonecfg:zoneA> add admin
zonecfg:zoneA> set user=alice
zonecfg:zoneA> set auths=manage
zonecfg:zoneA> end
zonecfg:zoneA> commit
zonecfg:zoneA> exit

Now lets look at the alternate method of storing this directly in the RBAC database, but we will show all our admins and zones for this example:

# usermod -P +'Zone Management' -A +solaris.zone.manage/zoneA alice

# usermod -A +solaris.zone.login/zoneB alice


# usermod -P +'Zone Management' -A +solaris.zone.manage/zoneB bob
# usermod -A +solaris.zone.manage/zoneC bob


# usermod -P +'Zone Management' -A +solaris.zone.manage/zoneC carl
# usermod -A +solaris.zone.manage/zoneD carl
# usermod -A +solaris.zone.manage/zoneE carl
# usermod -A +solaris.zone.manage/zoneF carl

In the above alice can only manage zoneA, bob can manage zoneB and zoneC and carl can manage zoneC through zoneF.  The user alice can also login on the console to zoneB but she can't do the operations that require the solaris.zone.manage authorisation on it.

Or if you have a large number of zones and/or admins or you just want to provide a layer of abstraction you can collect the authorisation lists into an RBAC profile and grant that to the admins, for example lets great an RBAC profile for the things that alice and carl can do.

# profiles -p 'Zone Group 1'
profiles:Zone Group 1> set desc="Zone Group 1"
profiles:Zone Group 1> add profile="Zone Management"
profiles:Zone Group 1> add auths=solaris.zone.manage/zoneA
profiles:Zone Group 1> add auths=solaris.zone.login/zoneB
profiles:Zone Group 1> commit
profiles:Zone Group 1> exit
# profiles -p 'Zone Group 3'
profiles:Zone Group 1> set desc="Zone Group 3"
profiles:Zone Group 1> add profile="Zone Management"
profiles:Zone Group 1> add auths=solaris.zone.manage/zoneD
profiles:Zone Group 1> add auths=solaris.zone.manage/zoneE
profiles:Zone Group 1> add auths=solaris.zone.manage/zoneF
profiles:Zone Group 1> commit
profiles:Zone Group 1> exit


Now instead of granting carl  and aliace the 'Zone Management' profile and the authorisations directly we can just give them the appropriate profile.

# usermod -P +'Zone Group 3' carl

# usermod -P +'Zone Group 1' alice


If we wanted to store the profile data and the profiles granted to the users in LDAP just add '-S ldap' to the profiles and usermod commands.

For a documentation overview see the description of the "admin" resource in zonecfg(1M), profiles(1) and usermod(1M)

Tuesday May 01, 2012

Podcast: Immutable Zones in Oracle Solaris 11

In this episode of the "Oracle Solaris: In a Class By Itself" podcast series, the focus is a bit more technical. I was interviewed by host Charlie Boyle, Senior Director of Solaris Product Marketing. We talked about a new feature in Oracle Solaris 11: immutable zones. Those are read-only root zones for highly secure deployment scenarios.

See also my previous blog post on Enctypted Immutable Zones.

Wednesday Feb 29, 2012

Solaris 11 has the security solution Linus wants for Desktop Linux

Recently Linus Torvalds was venting (his words!) about the frustrating requirement to keep giving his root password for common desktop tasks such as connecting to a wifi network or configuring printers.

Well I'm very pleased to say that the Solaris 11 desktop doesn't have this problem thanks to our RBAC system and how it is used including how it is tightly integrated into the desktop.

One of the new RBAC features in Solaris 11 is location context RBAC profiles, by default we grant the user on the system console (ie the one on the laptop or workstation locally at the physical keyboard/screen) the "Console User" profile.  Which on a default install has the necessary authorisations and execution profiles to do things like joining a wireless network, changing CPU power management, and using removal media.   The user created at initial install time also has the much more powerful "System Administrator" profile granted to them so they can do even more without being required to give a password for root (they also have access to the root role and the ability to use sudo).

Authorisations in Solaris RBAC (which dates back in main stream Solaris to Solaris 8 and even further 17+ years in Trusted Solaris) are checked by privileged programs and the whole point is so you don't have to reauthenticate.  SMF is a very heavy user of RBAC authorisations.  In the case of things like joining a wireless network it is privileged daemons that are checking the authorisations of the clients connecting to them (usually over a door)

In addition to that GNOME in Solaris 11 has been explicitly integrated with Solaris RBAC as well, any GNOME menu entry that needs to run with elevated privilege will be exectuted via Solaris RBAC mechanisms.  The panel works out the least intrusive way to get the program running for you.  For example if I select "Wireshark" from the GNOME panel menu it just starts - I don't get prompted for any root password - but it starts with the necessary privileges because GNOME on Solaris 11 knows that I have the "Network Management" RBAC profile which allows running /usr/sbin/wireshark with the net_rawaccess privilege.   If I didn't have "Network Management" directly but I had an RBAC role that had it then GNOME would use gksu to assume the role (which might be root) and in which case I would have been prompted for the role password.  If you are using roleauth=user that password is yours and if you are using pam_tty_tickets you won't keep getting prompted.

GNOME can even go further and not even present menu entries to users who don't have granted to them any RBAC profile that allows running those programs - this is useful in a large multi user system like a Sun Ray deployment.

If you want to do it the "old way" and use the CLI and/or give a root password for every "mundane" little thing, you can still do that too if you really want to.

So maybe Linus could try Solaris 11 desktop ;-)

Monday Feb 20, 2012

Solaris 11 Common Criteria Evaluation

Oracle Solaris 11 is now "In Evaluation" for Common Criteria at EAL4+.  The protection profile is OSPP with the following extended packages: AM - Advanced Management  EIA - Extended Identification and Authentication, LS - Label Security, VIRT - Virtualization.  For information on other Oracle products that are evaluated under Common Criteria or FIPS 140 please see the general Oracle Security Evalutions page.

Please email seceval_us@oracle.com for all inquiries regarding Oracle security evaluations, I can't answer questions about the content of the evaluation on this blog or directly by email to me.

About

Darrenmoffat-Oracle

Search

Categories
Archives
« August 2015
MonTueWedThuFriSatSun
     
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
      
Today