Casper Dik's Weblog

ACPICA in Solaris With the long history of neglect that Solaris on x86 endured, quite a few components got to be extremely stale and fragile. And this wasn't just a lack of device drivers but also a lack of basic new functionality in the core OS.

This week saw another quantum leap; the induction of Intel's ACPI reference implementation (ACPICA) into the next Solaris release.

For years I wanted to have battery support on my old VAIO and later on my Ferrari. And I wanted a power button that did something, etc. I tried to make do with the old "acpi_intp" interpreter which was part of Solaris; but it leaked memory like a sieve and was limited in functionality. Integrating ACPICA looked daunting but fortunately someone made an actual project out of this and the end result is that we now have a state of the art ACPI interpreter in Solaris.

There are basically only two ACPI interpreters in widespread use: the Windows one and the Intel one; by leveraging Intel's source, we stand a fair chance of having Solaris work with more ACPI BIOSes. If our system required ACPI to be turned of for Solaris to work, you may find yourself forced to switch it on when you upgrade later this year.

I've been distributing acpica and a number of other useful Solaris binaries in a single internal kit called "frkit" (originally aimed at Ferrari's but now running on countless systems); frkit includes acpica, a powerbutton/battery handler, an AMD PowerNOW! powermanagement module, a GNOME battery monitor, and our development cardbus and wireless drivers + tools.

One of the more interesting parts of that is possibly the "NDISulator" port from FreeBSD which allows the Sun Ferraristi to use the builtin Broadcom wireless on their ACer Ferraris in 32 and 64 bit mode.

ACPICA is just phase one of a larger project; we have not yet bothered much with the "P" (for power) from ACPI; but we hope to leverage the new implementation to provide the necessary "S3" and "S4" sleep state support.

The speed at with new features work on my Ferrari which I've had now for 4 months is in stark contrast with my Vaio which I got not too long before S9 for x86 was postponed. It's clear that we needed a ramp-up after the wind-down, but it seems to be going more quickly than ever before. (2005-04-20 02:46:56.0) Permalink Comments [10]

USB hotplug finally works Today I was pleasantly surprised to see the latest putback to SNV, our next Solaris release (soon on a OpenSOlaris source server near you)

Before this putback you could hotplug/eject devices into devices (SD cards and such in card readers, floppies in floppy drives) but you had to restart vold to mount USB pen drives. But now, you can insert them, remove them, etc, and they're mounted and unmounted automatically.

This was really one of my most wanted features and its great to finally have it. Will it make an update? I certainly hope so; but you can always try Sun Express. (2005-04-19 13:11:40.0) Permalink Comments [3]

Solaris 10 Encryption Supplement download The Solaris 10 encryption supplement is available for download here. Apparently, it's difficult to find going through the Sun download sides so I give a link here.

The supplement adds 256 bit AES and 448 bit Blowfish; DES, 3DES, 128 bit AES, blowfish and RC4 are already in the standard release. In other words, the standard release gets you what you would have gotten with the encryption supplement for older releases. And the S10 Encryption Supplement takes it one step further. The main reason for not making this part of the Solaris CDs is import restrictions, rather than export restrictions.
(2005-04-14 05:45:15.0) Permalink Comments [2]

Timezones and multi boot. One of the things that has always been bothering me is the fact that on x86 systems you cannot really run multiple operating systems and survice the timezone change. That's because the clock runs in local time; and localtime is ambiguous. The system cannot tell whether the DST change has been or not so it needs to record this fact in the filesystem (that's why Solaris on x86 has the "rtc -c" cronjob). If you boot all your OSes in turn after the changeover, your system will be N hours off once they're all done adjusting time. The problem is probably best summarized here

On Unix this was long solved by running the clock in the UTC or GMT timezone; that clock is unambiguous, give or take a leap second, and allows multiple versions of the OS to coexist.

Last week, it was pointed out to me in comp.unix.solaris that there is a hidden registry key in later releases of MS-Windows. I already knew how to fix up Solaris, so I combined this to:

       Set the following registry key (it does not exist!)

HKLM/SYSTEM/CurrentControlSet/Control/TimeZoneInformation/RealTimeIsUniversal
(REG_DWORD = 1)

       In the control panel with Day&Time settings, check the "automatically adjust" check box.


        Boot into Solaris and run:


              rtc -c -z UTC

        then correct the clock with date/rdate
        (if you use liveupgrade, lumount your other partition(s) and copy the
        /etc/rtc_config file to all of them)

        In Linux, you'll need to run "timeconfig" and select "RTC set to GMT".

Note that if you don't multiboot, it's probably also a good idea to run "rtc -c -z UTC" and then correct the date; for one you won't be bitten by the AMD64 timezone bug we had in Solaris 10. (2005-04-12 06:13:30.0) Permalink Comments [4]

Open Solaris CAB It has been a busy week flying to SFO and having our first CAB meeting. The first good thing that happened was that KLM had finally changed the aging and horrible MD11 for shiny new Boeing 777s with personal video. I have a bit of a problem with the new immigration procedures, and I like the Brazilian's government stand on this.
I had met Rich Teer fleetingly before in the hallways of the Menlo Park Campus so he recognized me when we checked in at the same time; we probably were on the same BART train from the airport. But I had never met the others. I feel we have a great team with very many different competences, from Roy Fielding's experience with Apache's governance model, Simon Phipps' tireless evangelism. And Al Hopper with his tireless Solaris on x86 enthusiasm. Rich Teer, a SPARC fan, and accomplished author and myself as Solaris engineering representative, being the more technical side of things.
Are we just marketing as the Register would have it? No, we're very serious about it. Is the CAB just a bunch of YES-men? Can we get the respect of our community if we are?
Sun takes both Open Solaris and the independence from Sun serious; Jonathan Schwartz came to meet us but none of the other executives was allowed at our meeting. He talked to us at length and was very serious about clearing up the roadblocks that we had already determined to be on the path to OpenSolaris. It is clear that they want us to succeed and want us to independent. Jonathan even stayed for lunch.
The Sun press conference we took part in was a first for me. The press was not hostile and mostly asked questions which were to the point; some more than others.
We have a lot of work to do and will do most of it in email on a publicly readable mailing list.
The second day we listened to Jonathan's keynote at the OSBC conference and spend the afternoon doing interviews with the press followed by a press reception and Sun engineering diner/Open Solaris launch party at Lulu's. And guess what, we were able to make the Americans walk all over town, the itenary was all "5 min cab ride" and some such nonsense.
On the final day I took Ben Rockwood's advice and tried out "Clam chowder in sourdough" after taking the cable car to lombard street and walking down to the harbor. The weather was gorgeous, the same cannot be said of the weather in Amsterdam which is now unseasonably cold.
(2005-04-09 05:44:32.0) Permalink Comments [3]

Blowout!

Sometimes completely unexpected events take place such as this little mishap with our car; modern MPVs are pretty forgiving and you might not immediately notice that you've got a flat, especially not if the driver hasn't driven the particular vehicle for a while, you have the fans blowing and are playing music at the same time. Until you hit the highway, that is. So, what happened next? A lot of noise and a rather poignant smell of burning rubber before we even hit 50 or 60 and in the few seconds we figured out that we had to pull over, the tire give way ; it had half left the rim before we came to a full stop on the hard shoulder. And here's what's left of it:


With cars zooming past at 120kmph(75mph) on a fairly narrow stretch of highway on a cold dark night with wife and kids in the car, you feel like someone has just painted a target sign on you and you anxiously wait until the help arrives. And they did, within 5 or 10 minutes. (2004-12-10 15:09:51.0) Permalink

Fujitsu Lifebook B112 running Solaris 10

As one of two resident Solaris Engineers in Holland, you sometimes get strange requests such as one from an IT operations person who was given this really old laptop. A fujitsu Lifebook B112; 96MB, 3GB harddisk. It was running Solaris 7 and he had no root password.

Hacking it was not too difficult; installing Solaris 10, of course, would be more fun.

There are a few challenges getting a vintage laptop up and running; it has no onboard networking, no bootable CD. And Solaris 10 does not support booting from the Xircom PE3 parallel port ethernet card anymore. And where would you even find such a device?

Well, turns out that we were indeed able to locate a Xicrom PE3 adaptor and armed with "perl" we could make the S9 "pe" driver run under S10; the "pe" driver is no longer supported because we obsolete GLDv0 but by making PE load "misc/GLD" rather than "misc/gld" and installing the old GLD driver we added the device to the miniroot on the S10 install server. Armed with an S9 boot floppy we then booted S10 from the server and started the install. It couldn't fit all of Solaris 10 so we removed a few components to cut it down so it would fit in the 2.8GB partition (the installer is a bit generous in allocating space so at the end we only had 2.0 GB installed).

After churning for around 3 hours, Solaris had been installed (Pe ethernet is very slow and a 233MHz Pentium is not very fast). I had to go home (friday) and resolved to see how far we'd get on monday. But I couldn't wait.

The next hack was attacking a system sitting idle with install finished (we didn't dare reboot because it'd come up w/o ethernet if we did) from the install server. After looking with snoop I found that there are actually two ways of doing that: the first one is the new "eventhook" mechanism we have for dhcp; whenever a dhcp event occurs, the eventhook script is run. The second method was even simpler; it turns out that Solaris 10 init stat's inittab every 5 minutes. So I added a line to inittab which popped an xterm up over my VPN tunnel to my house. Added the "PE" ethernet driver; finished some other config stuff by hand and rebooted. And it came up, still with PE but I soon killed it remotely fiddling with cardbus and the PCMCIA Ethernet card.

With my own modified PCIC driver I was able to get the lifebook to use "pcelx0", with all supported devices. Xorg came up without a hitch too, just a little bit of fiddling to get it to use the External monitor; no luck with the touchscreen yet. Here's what it looked like

Even sound was simple; ``update_drv -a -i '"ESS1879"' sbpro'' and the sound driver attached. (2004-11-29 05:32:51.0) Permalink Comments [4]

The Solaris BOF Yesterday's Solaris BOF at the Usenix Security symposium was well attended (about 70 people); there were great many questions about zones which shows there is a great interest in the topic. (I di both a zones and a privilege application).

Talking to many people in the hallways of the conference is great and I'm still tackled with questions the day after the BOF (we ran out of time, on questions). (2004-08-12 12:29:48.0) Permalink

Solaris Privileges

So what makes Solaris Privileges different? Why didn't we copy something else like Trusted Solaris Privileges or "POSIX" capabilities?

Let's start from what we formulated as our requirements near the beginning of our project.

One of the important features of Solaris is complete binary backward compatibility; in order to offer that we needed to design the privilege subsystem in such a manner that current practices, binaries and products would continue to work. Of course, some have solved this issue by providing a system wide knob to turn: root / root + privileges / just privileges. We don't like knobs in our OS; specifically not ones which drastically alter the behaviour of a system. It makes it harder to develop software; it needs to work for all settings. Certain products may require conflicting settings, and so on. So we decided on a "per-process" knob which is largely automatic

With backward compatibility comes the onus on the software developer to develop future proof interfaces; that ruled out all other interfaces as they all have fixed bitmaps and fixed privilege/capability numbers, fixed structure sizes in the programmer visible parts of the system. Solaris Privileges have none of that. And while we could savely reuse the names of the Trusted Solaris interfaces we can not redefine interfaces even from a defunct standard. So we have interfaces which smell like Trusted Solaris but with a completely new userland representation of privileges and privilege sets. We can never have more signals; but we can have more privileges and more privilege sets!

The privileges and privilege sets in Solaris 10 are represented to userland processes and non-core kernel modules as strings; privilege sets are bitmasks of undetermined size; they can only be allocated through the C library routines. Privilege set names are also strings and not plain integer indices; this gives us even more flexibility. A Solaris binary compiled for 4 privilege sets of each 32 privileges will continue to work on a Solaris system with 5 privilege sets each of which can contain 64 privileges and with all the privileges having their internal representation renumbered.

Evolving from the Super user model

The traditional super user model is fairly straighforward; a process has three uids associated with it the effective uid, the real uid and the saved uid. A privileged process is a process which runs with an effective uid 0. A process can temporarily relinquish privileges by setting the effective uid back to the real uid; the saved uid remains 0 or can be set to the real user id as well; in the latter case the process has permanently relinquished its privileged status. But if the saved uid is 0 the process can swap the effective uid back and forth, implementing some form of privilege bracketing. Of course, once such a process is compromised, an exploit can also swap the effective uid back to 0. And the only choice is to have all privileges available or none.

In your typical Unix privilege model the powers formaly associated with uid 0 (PFAWU0) are split into a number of privileges; each process has three different privilege sets; the Effective, Permitted and Inheritable sets, or E, P and I, for short. E closely models the effective uid and P is very much like the saved/real uids: the Effective set determines which privileges a process has active; this is the set of privileges the kernel verifies its privilege checks against. The Permitted set is very much like the saved set; it contains privileges a process is allowed to use. So a process is free to remove any privilege from E and a process is free to add whatever privilege he wants to E as long as it carries that privilege in P. The Inheritable set allows a process to pass privileges on to sub processes; e.g., in case you want to run a webserver with a particular uid but with the additional privilege allowing it to bind to port 80. You put the privilege in the inheritable set (if it is in your permitted or effective set) and the executable will run with that privilege. Privilege bracketing is then performed by adding privileges to E and removing them from E; when a process is done and wishes to relinquish all privileges forever, it removes them from P (which automatically causes removal from E). The fourth privilege set we use in Solaris is the "Limit" set. The privilege set is the upper limit of privilege a process and its off-spring can ever obtain. Solaris uses the limit set for a number of additional things; it is used to restrict the power of the super user in non-global zones and it is used as a mechanism to determine with what privileges a backward compatible uid 0 process runs with.

So how is this compatibility achieved? Well, after a long debate the answer we came up with was really simple: if we want an implementation to be backward compatible for applications which don't know better, what's simpler than a single per-process knob? This know we've called "Privilege Awareness" (PA) and in order to explain this we introduce the notion of Observability; and we make the kernel operate on the observed effective (E^O) and observed permitted (P^O) set; these contrast with the implementation sets, the actual bits in the kernel credential for a process. The kernel then sees the privilege sets as follows:

E^O = euid == 0 && !PA ? L : E^I
P^O = any uid == 0 && !PA ? L : P^I

The observed set closely follows the effective uid and the permitted set models the fact that if any of your uids is 0 you can recover an effective uid of 0. A process becomes privilege aware if it modifies its E or P set or when it requests to become privilege aware. A PA process can also request to become non-PA but such a transition is only possible if the observed sets can be made to remain constant on such a transition. The kernel will try to drop PAness on exec().

The privilege sets can be modified by the process itself but the kernel modifies them also at exec(2) time using the following rules:

            I' = L & I               (L intersected with I)
            E' = P' = I'
            L remains unchanged

For your typical process this is a noop, as the typical process has the following privileges:

            I = P = E = { basic }
            L = { all zone privileges }

As seen here, the system defines a set of privileges known as the "basic" set; it is a set of privileges requires for operations which traditionally weren't privileged in Unix; the design of the basic privilege set and the specific rules about its use make sure that it too can be extended in future with new privileges, without requiring applications which use the feature now privilege to be modified. The current set of basic privileges in Solaris are the privilege needed to fork(), a privilege needed to exec(), a privilege needed to create hardlinks to files not owned by the current effective uid, a privilege needed to send signal to processes outside of your current session and the privilege needed to see other user's processes.
In order to properly work in an environment with a changed basic set, a process would specify the privileges it needs as the basic set + non basic privileges minus the basic privileges it knows it doesn't need. When the basic set is then extended in a later Solaris release the process is guaranteed to continue to work.

What I've outlined up to this point is mostly an enabling technology; in and by itself it does not make the system more secure; but it allows us to harden the system and reduce the risk.

Why privileges should not be orthogonal

My background is very much a hardening background and not a Trusted Computing background; so I have always felt that the privilege model as employed in a number of operating systems has one serious weakness: most of these operating systems define privileges which allow you to acquire more privileges. Typical for such privileges are single privileges which allow you to write directly to disks or kernel memory. What is the point of such privileges? You can just as well give process requiring such privileges all privileges. In Solaris we have defined a very simple rule which I've dubbed The principle of privilege escalation prevention; the basic rule is this: "an operation needs at least as many privileges to be performed as can be gained by executing it". Simply put: if you want to write to /dev/kmem, you will need all privileges! If you want to control a process, you will need at least as many privilege as a process has. If you want to assign privileges to another process, you must have those privileges. If you want to mount on top of something, you must own that something.

And when we find more of such holes we will plug them. Of course, we still have a little bit of a problem with the user with uid 0: he still own all the files and we have not restricted him in writing to his files. So in order to practice safe computing, run with a different uid and perhaps a few extra privileges.

Any, that's all for today of to the beach and see you in two weeks or so. Or see you at Usenix security in San Diego! In the next episode we'l shed some light on the repercussions of changing the credential and the visible changes obviated in userland; we'll answer such important questions as "will door_cred()" survive privileges? (2004-07-22 13:54:41.0) Permalink Comments [1]

Some S10 features
Wow, three comments without actually writing something interesting!

I'm actually off for a two week vacation starting tomorrow, but perhaps I should start with a list of things that I have done for Solaris 10.

By far the biggest thing I've done are Solaris privileges; it leans somewhat on Trusted Solaris but it has some fairly unique features.

But we've also been playing "catch-up", i.e., including features missing from Solaris but commonly found elsewhere.

The list looks somewhat like this.

Solaris Privileges.
TCP wrapped rpcbind.
noexec mount option (solaris 10 also separates nosuid in nosetuid and nodevices).
getpeerucred(2) and ucred_get(3C).
mktemp(1)
pcred(1) updates (set credentials of running process)

(2004-07-22 06:43:57.0) Permalink Comments [1]

As I've been posting to Usenet since 1988, I didn't think it would be so hard to start a weblog; but in Usenet I have been mostly reactive, replying to other people's questions, answers and thoughts.

A weblog feels like talking into thin air.

As I work specifically for Solaris Security I will be focussing on a few things that I have done for Solaris 10 which I think are neat. I'll try to explain some of the design decision we made and how and why they are different from, e.g., Trusted Solaris and other systems with similar features. Stay tuned.

(And yes, I will update the Solaris FAQ too, in a while) (2004-07-08 00:21:55.0) Permalink Comments [4]