Linux Brandz removed from ON

ONNV build 143 is a important for every one of us that uses lx Branded Zones - the Linux ones. There have been a stall in development since some time and forums are full of people looking for ways to install anything newer than CentOS images provided by the project. But since the build 143 Linux Brandz will be removed. If you you is too, like me, you have to plan for some migration.
And so Linux Brandz go away: http://static.opensolaris.org/on/flagdays/pages/20100612010403.html

SFE bootstrap script

Thanks to Tommw, who maintains sfe bootstrap script, you can set up a complete SFE compilation ready environment in few simple moves.
The script can be downloaded from here: http://tinyurl.com/bootstrap-sfe-latest-os20nn. Just use wget:

1. wget -N "http://tinyurl.com/bootstrap-sfe-latest-os20nn"


2. chmod a+rx bootstrap-sfe-latest-os20nn


3. ./bootstrap-sfe-latest-os20nn username

Username is a login of a user that you'll use for compilation. The script does all the magic, just answer two or three simple questions - user's password.
Before you begin, you may want to:

• Create a user that will be responsible for compilation. User should have a "Software Installation" profile assigned. I use my main user, who has both Software Installation and Primary Administrator profiles.

• pfexec pkg install wget

• Enable local repository, as pkgbuild will want to push packges to your IPS repository. This is a link to repository setup instructions. Go on, it's friggin easy.

Remember to send Thanks e-mail to address printed after the bootstrap script finishes.

PSARC 2009/377; 2009/378; 2010/072

PSARC 2009/377

• In-kernel pfexec implementation.

PSARC 2009/378

• Basic File Privileges

PSARC 2010/072

• RBAC update: user attrs from profiles,


• 4912090 pfzsh(1) should exist,


• 4912093 pfbash(1) should exist,


• 4912096 pftcsh(1) should exist,


• 6440298 Expand the basic privilege set in order to restrict file access,
  
• 6859862 Move pfexec into the kernel, [that one is interesting - trochej]


• 6919171 cred_t sidesteps kmem_debug; we need to be able to detect bad hold/

pfexec is a kind of sudo, right?

(Open)Solaris can cause some emotional turmoil in new users coming from Linux background. Its ifconfig works bit differently, load average is calculated differently, and so on, et caetera...
One of things that leave people rather puzzled is authorisation mechanism based on system roles: Role Based Access Control (RBAC). As always, you're encouraged to read fantastic docyumentation: System Administration Guide: Security Services, chapterł Roles, Rights Profiles, and Privileges. However, to make a very short introduction, RBAC defines roles and profiles that have assigned privileges (authorisations) regarding use of commands. Something like sudo, at the first sight. Those roles and profiles can be assigned to concrete users. Something like sudo. The first difference is simply cosmetic. Instead of invoking 'sudo' in front of privileged command, one invokes 'pfexec'. The second difference is strictly work based. RBAC (pfexec) comes with multitude of profiles and roles ready to be used. For last few years I used OpenSolaris I prepared new profile just once.
Third difference lays in profiled shells, ie. pfsh. If a user is assigned a profile and given a profiled shell, they will be able to invoke only commands which are assigned to said profile, but without using the pfexec keyword.
Fourth difference are roles. Roles are basically user accounts that cannot be logged into directly. One has to use su command to log into the roles. Also, user can only logged into the role which has been assigned to them. This is the default use of root account in OpenSolaris distribution.
Fifth difference is big. RBAC reaches deeply in structure of (Open)Solaris, down to special kernel structures. This, along with rbac programming libraries, allows to implement very fine grained security into programs written. So, a fragment of code can check, if invoking user has, say, authorisation to write to log files, and then do some action.

Anatomy.

RBAC is built of three logic elements:

• authorisations - users rights to use privileged functions,


• execution profiles - a way of combining authorisations and command with attributes, ie. UID of command,


• roles - accounts explained before

Authorisations are defined in a system file /etc/security/auth_attr.
Users get profiles, roles and authorisations assigned in a file /etc/user_attr. Some fun fact. Some time ago blogs and howtos instructed that to assign a role, profile or authorisation to user, one had to edit said file. However, it is officially discouraged way. Better way is to use commands. Commands are guaranteed not to break the file. It is important to understand, that broken profile in /etc/user_attr may render user unable to user any privileged commands, login to root account and so on.
Authorisation definitions are written in a file /etc/security/prof_attr.
And the most important, I think - definitions of privileged operations assigned to profiles are written in a file /etc/security/exec_attr.
I won't indulge in details, as those are well explained in documentation (man man, people!). I'll only mention, that commands assigned to security profile are listed in /etc/security/exec_attr. A bit mysterious is file /etc/security/auth_attr. When I studied RBAC I was puzzled. All other files are intertwined together and it is rather easy to trace how they work together, but I couldn't figure out this one, as I couldn't find any sign of listed there attributes any other place. It turns out, that this is the mechanism for implementing rbac in applications. A code can do a check against any authorisation listed in the file and if a user is assigned one, application may take certain actions.

Commands
Managing RBAC is nased on few commands.

• roles - prints list of roles assigned to a user,


• profiles - prints a list of users profiles. profiles -l prints authorisations and privileged commands of users every profile,


• auths - prints list of users authorisations,


• roleadd - creates a role, syntax similar to useradd,


• rolemod - modifies a role,


• useradd: option -P accepts list of profiles as its argument, option -R accepts list of roles, option -A accepts list of athorisations,


• usermod: option -P accepts list of profiles as its argument, option -R accepts list of roles, option -A accepts list of athorisations.

WARNING!
rolemod and usermod overwrite assigned privileges. If one wants to assign a profile Software Installation to user that already has Primary Administrator, usermod line looks like that:

pfexec usermod -P "Primary Administrator,Software Installation" username

More information in manpages and : System Administration Guide: Security Services, chapter Roles, Rights Profiles, and Privileges.

beadm

In my last post I wrote a short howto to handmade zfs rpool cloning. It takes only a few steps, but forgetting one of them may provide wrong results. But OpenSolaris has one nice tool to do it all for you:

beadm create opensolaris-2

Simply do it, and your system will be cloned, your grub will have a new entry and the new filesystem's /etc/vfstab will have it's '/' entry corrected.
Now, why not do a clone every few days, just in case you ever remove your '/etc'?

Playing with fire

Following losely Indiana update guidelines found here I have done a clone of my root filesystem. Then I have fooled around with it a little bit.

zfs snapshot rpool/ROOT/opensolairs@for-cloning
zfs clone rpool/ROOT/opensolaris@for-cloning rpool/ROOT/opensolaris-1
zfs set mountpoint=legacy rpool/ROOT/opensolaris-1
mount -F zfs rpool/ROOT/opensolaris-1 /mnt
vim /mnt/etc/vfstab

Here I have replaced rpool/ROOT/opensolaris with rpool/ROOT/opensolaris-1. I yet edited /rpool/boot/grub/menu.lst by copying an OpenSolaris entry and changing the bootfs rpool/ROOT/opensolaris line in the copy to bootfs rpool/ROOT/opensolaris-1. In the end I had two different entries in grub boot menu.
I then did:

rm -rf /platform/

and rebooted. In the above one line I have effectively wiped out kernel and boot_archive. It came as no surprise, that grub complained that it couldn't boot my old system. Oh well, I choose the second entry, booted from the clone, promoted it with zfs promote, destroyed the old system, which became the clone now, and type to you quite happily from working OpenSolaris 2008.05.
Have a Nice day.

ZFS snapshots

I started to like them. I became accustomed to create a snapshot of my filesystems periodically, just as I click Save button in Editors. Really nice feature, which makes my life easier. Undelete is almost obsolete. :)
For interested:


-bash-3.2# cat /usr/bin/zfs_snapshot.sh
#!/bin/sh

zfs snapshot -r rpool@`date +%Y-%m-%d:-:%H:%M`



-bash-3.2# time zfs_snapshot.sh

real 0m1.257s
user 0m0.014s
sys 0m0.023s

-bash-3.2# zfs list
NAME USED AVAIL REFER MOUNTPOINT
rpool 21,2G 67,9G 56,5K /rpool
rpool/ROOT 5,94G 67,9G 18K /rpool/ROOT
rpool/ROOT/opensolaris-1 5,94G 67,9G 5,28G legacy
rpool/ROOT/opensolaris-1@2008-05-09:-:22:59 0 - 5,28G -
rpool/ROOT/opensolaris-1/opt 673M 67,9G 673M /opt
rpool/ROOT/opensolaris-1/opt@2008-05-09:-:22:59 0 - 673M -
rpool/export 15,2G 67,9G 19K /export
rpool/export/home 15,2G 67,9G 15,2G /export/home
rpool/export/home@2008-05-09:-:22:59 70,5K - 15,2G -