I finally found an app that will let me have a branded zone booted at all times: Google Earth.

Works (mostly) out of the box. I had to step down the graphics ("use safe graphics") in order for it to render well, but that's all. I'm seriously impressed that this works so well being "ssh -X"ed into the Branded zone... kuddos to the folks who made this work!

And man, do I like the view from this restaurant.. ;-)

Announcing NLOSUG, the Dutch OpenSolaris User Group Third Meeting

This meeting is sponsored by SNOW Unix Specialists[1]

For the first time, we provide dial-in access to the UserGroup meeting. See [2] for dial-in details.

When	May 3, 2007, 19:00-22:00
Where	Zalencentrum Waardenburg Regterweistraat 5-7 4181 CE Waardenburg http://www.zalencentrumwaardenburg.nl/
Register	http://www.nlosug.org

On Thursday May 3d, 2007, the Dutch OpenSolaris User Group will hold its third meeting at Zalencentrum Waardenburg in Waardenburg. Solaris developers, users, enthusiasts,experts and novices are all welcome.

Theme for this meeting is: Network Virtualisation with Crossbow.

We will start at 19:30, agenda as follows:

• Bart Muijzer, NLOSUG host, will give an update on the group, share some ideas of where it's going, and lead a group discussion.
• A Project Crossbow Core Team member will introduce SUNs upcoming solutions on Network Virtualisation and share deep technical details on the OpenSolaris Crossbow project[3].
• life discussions and Q&A.

Of course there will be plenty of time for socializing and networking, and we'll have food and drinks on hand.

We plan to end around 22:00 with food and drinks at the bar.

Please register at: http://www.nlosug.org/ .

We hope to see you all on May 3d!

[1] http://www.snow.nl/
[2] http://www.nlosug.org/
[3] http://opensolaris.org/os/project/crossbow/

Todays release of OpenSolaris will hopefully invite many of you out there to contribute your own code or have it available on OpenSolaris as well as on the other platforms you live on. To help you do so securely, I'll mention a potpourri of OpenSolaris features that we think help to make your code more secure.

Introduction of O_NOFOLLOW and O_NOLINKS

In Solaris 10, and thus now in OpenSolaris, we introduced two new flags to open(2) with the following description:

O_NOFOLLOW	If the path names a symbolic link, open() fails and sets errno to ELOOP.
O_NOLINKS	If the link count of the named file is greater than 1, open() fails and sets errno to EMLINK.

While O_NOFOLLOW certainly isn't new to UNIX, the addition of O_NOLINKS is. With these two flags, constructs like the open/stat-dance we used previously should become something of the past. In pseudo-code we did something like

	if (lstat(fname, &lsb) == -1) {
		fd = open(fname, O_CREAT|O_EXCL|O_WRONLY, 0600);
		if (fd == -1 && errno == EEXIST) {
			/* start afresh */
			...
		}
	} else if (S_ISLNK(lsb.st_mode)) {
		/* fail, symbolic link */
	} else {
		if ((fd = open(fname, O_WRONLY)) != -1) {
			if (fstat(fd, &fsb) != -1) {
				if (fsb.st_nlink > 1)
					/* fail, too many links */
				else if (fsb.st_dev != lsb.st_dev ||
			 	    fsb.st_ino != lsb.st_ino) {
					/* fail, file changed after lstat */
				}
			}
		}
		/* success */
	}

Now, we can do

	fd = open(fname, O_CREAT|O_NOFOLLOW|O_NOLINKS, 0600);

Of course, if you want to make sure that you don't open any special files (devices), you'll still have to lstat()/fstat() and check for S_ISREG(). I hoped to introduce O_REGULAR too, but that didn't make it (yet? :-).

Non-executable stacks

Not new to Solaris, but maybe new to you, and certainly worth pointing out: large parts of Solaris, at least the commands in ON (the Operating System and Networking part of Solaris) are built with the stack-segment mapped as non-executable memory. Of course, this will not stop people from exploiting stack-overflows, but it'll surely make it harder to do.

Check out the definition of NES_MAPFILE in usr/src/cmd/Makefile.cmd. It defines an option passed to the linker (through the C-compiler front-end) that tells it to use a mapfile (mapfile_noexstk) that contains

stack = STACK ?RW;

This line is a segment declaration that tells the runtime linker to create the applications stack segment with the Read and Write flags enabled, but the eXecute flag unset. You can check which flags for the stack segment of a particular binary are set by running elfdump(1) on the binary. Search for an ELF section of type PT_SUNWSTACK, as in

$ elfdump /bin/ls 

ELF Header
  ei_magic:   { 0x7f, E, L, F }
  ei_class:   ELFCLASS32          ei_data:      ELFDATA2MSB
  e_machine:  EM_SPARC            e_version:    EV_CURRENT
  e_type:     ET_EXEC
  e_flags:                     0
  e_entry:               0x10e48  e_ehsize:     52  e_shstrndx:   21
  e_shoff:                0x6718  e_shentsize:  40  e_shnum:      23
  e_phoff:                  0x34  e_phentsize:  32  e_phnum:       6

Program Header[0]:
    p_vaddr:      0x10034         p_flags:    [ PF_X  PF_R ]
    p_paddr:      0               p_type:     [ PT_PHDR ]
    p_filesz:     0xc0            p_memsz:    0xc0
    p_offset:     0x34            p_align:    0
...
Program Header[5]:
    p_vaddr:      0               p_flags:    [ PF_W  PF_R ]
    p_paddr:      0               p_type:     [ PT_SUNWSTACK ]
    p_filesz:     0               p_memsz:    0
    p_offset:     0               p_align:    0

As shown here, the stack segment of /bin/ls is mapped with the PF_W and PF_R, and not with PF_X. Some example mapfiles can be found in /usr/lib/ld, like /usr/lib/ld/map.noexdata, which shows how to map data-segments without the executable bit set (for use on x86 machines). More info on mapfiles (and the linker in general) can be found in the Software Developer Collection on docs.sun.com.

lint security checking

If you've looked at the Makefiles in OpenSolaris, you may have encountered the -errsecurity flag that is passed on to lint. Specifying this flag makes lint perform several static checks on your code that helps keeping you (me?) alert when coding. It won't of course fix any of the logic bugs that are present, but it'll alert you when you use one of the known insecure functions that are part of any POSIX-like UNIX.

There are three levels of complaining that lint will perform for you, core, standard and extended. By default, the Solaris Makefiles set this to "core" which include these checks

• Use of variable format strings with the printf() and scanf() family of functions
• Use of unbounded string (%s) formats in scanf() functions
• Use of functions with no safe usage: gets(), cftime(), ascftime(), creat()
• Incorrect use of open() with O_CREAT

New code to Solaris should not introduce any new lint-warnings on the core level, but I'd suggest you run it with standard or extended on any code you change or introduce. For more info on this option, see section 5.3.13 of the lint Source Code Checker.

Least privilege

Glenn Brunette already showed an example of how to convert an existing setuid application (ping) into a privilege-aware application. There is more information on how to develop privilege aware applications in the Solaris Security for Developers Guide, but I thought I'd just show a little bit of one of the privilege-aware daemons, the NFS daemon nfsd.

Right after starting up, the NFS daemon uses its initial privileges to create a lockfile in a root-owned directory (_create_daemon_lock). It needs all privileges to do so, since it modifies an object owned by "root".

All that it needs from now on, is the privilege to bind to a reserved port (the nfs-port); nothing more, nothing less. Thus the call to __init_daemon_priv which is a convenience routine around a number of calls to setppriv() and setreuid() and setgid().

Once this routine returns, the daemon runs with just the privilege of a normal process (>tt>basic) augmented with the privilege to bind to the NFS port (sys_nfs). No more special "root" like privileges from this point on. In this way, we can perform the argument parsing and other initialization code using minimized privileges that limit the impact of a possible bug in the start-up code.

After the daemon has registered itself for the various protocols it is supposed to support (calls to do_one and do_one), it relinquishes even more privileges. For example, It gives up its right to fork(2) and exec(2) other binaries. For this it uses another convenience rapper-function called __fini_daemon_priv() which removes the listed privileges from the set of permitted privileges (which also removes them from the effective set).

When this routine completes, the nfs daemon runs with the following set of privileges:

# ppriv -v `pgrep nfsd`
5239:   /export/ws/work/usr/src/cmd/fs.d/nfs/nfsd/nfsd
flags = PRIV_AWARE
        E: sys_nfs
        I: none
        P: sys_nfs
        L: none

So, IF someone would be able exploit, e.g., a stack overflow bug in nfsd, it the exploit code would not only run as (daemon, daemon) without any basic privilege, it would also need to run in the address space of the daemon itself since it can't fork() nor exec().

Makes for a pretty useless target to attack, not?

---

Technorati Tag: OpenSolaris
Technorati Tag: Solaris

Hello World,

Since I will come out of the shadows of our SCCS history one day real soon now I might do a proper introduction as well... So: Hi! I'm Joep Vesseur. I'm a staff engineer at the Solaris Security and Networking Technologies group where I've been working since I joined Sun in 2000.

I'm based in the Netherlands and share--a rather nice, for a change-- office with Casper Dik, the man who posts more than he should.

Before working for Sun I worked as a researcher at the Computer Crime department of the Forensic Science Laboratories and as a developer at the Computer and Network Group at the University of Amsterdam.

My roots lie in the area of Parallel Scientific Computing, but I was mostly interested in the the "Parallel Computing" part. I've had quite a lot of fun on the institutes 512-node Parsytec GCel which looked quite sexy for its time (1994) (and no, that's not me in the picture). I also spent some time at Parsytecs' Chemnitz office developing parts of their OS for the Parsytec CC (PowerPC based platform). Interesting times...

At Sun, I largely focus on all things PAM which I hope to tell more about once OpenSolaris has set sail. Till then!