Fedora security Planet

Adam Young: Signed Authentication and Authorization

2012-05-16T14:31:05+00:00

Openstack Keystone currently operates on-line validation for Tokens. Once a token is issued out, each of the systems presented with the token has to check the validity of the token with the Keystone server. This makes Keystone the highest traffic service in an Openstack deployment. Using Cryptographic Message Syntax (CMS) we can generated a token that can be verified using public key cryptography instead of making a network call. Here’s a proof-of-concept example using the command line tools.

For authorization, we need a user name. For authentication, we need a tenancy and a set of roles that the user has in the tenancy.
Authorization cannot be for ever, so we need an expiration date/time. Here is a simple JSON representation of that data.

{"user": "ayoung",
"tenant": "coop-city",
"role": ["hallmonitor, groundskeeper"],
"expiry":"18JUL2012"
}

Note that it has the Roles listed in it. By cryptographically verifying this document, not only does it remove the need to validate the token with Keystone, but it removes the need to go back to keystone to fetch the roles. Thus, authentication and authorization information are linked in one document.

The following assumes you have a signing certificate. See the steps here to generate one if you need it.

To Sign auth_token.json run:

cmsutil -S -d alias -N ayoung -i auth_token.json -o auth_token.p7s

The signed message is put into auth_token.p7s, a file extension that alludes to the PKCS 7 standard.

This includes all of the certificates. Use a tool to view the contents in human readable form:

 /usr/lib64/nss/unsupported-tools/derdump -i auth_token.p7s

The output is big. To simply read the message back, use:

cmsutil  -D -i auth_token.p7s  -d alias/ -h1

This gives back the additional file, along with the validated signer:

SMIME: 	level=1.2; type=signedData; nsigners=1;
		signer0.id="Adam Young"; signer0.status=GoodSignature;
	level=1.1; type=data;
{"user": "ayoung",
"tenant": "coop-city",
"role": ["hallmonitor, groundskeeper"],
"expiry":"18JUL2012"
}

To simply check if the document is valid, drop the h1 argument. If to test it against an NSS database that does not have the CA cert in it, you get:

# cmsutil  -D -i auth_token.p7s  -d altdb

signer 0 status = SigningCertNotTrusted
cmsutil: problem decoding: Peer's Certificate issuer is not recognized.

To make this usable as a replacement for the current token scheme, we could use something like Base64 encoding:

[ayoung@ayoung cmstest]$ base64 auth_token.p7s
MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAaCAJIAEbXsidXNl
ciI6ICJheW91bmciLCAgCiJ0ZW5hbnQiOiAiY29vcC1jaXR5IiwgIAoicm9sZSI6IFsiaGFsbG1v
bml0b3IsIGdyb3VuZHNrZWVwZXIiXSwKImV4cGlyeSI6IjE4SlVMMjAxMiIKfQoAAAAAAACgggIG
MIICAjCCAWugAwIBAgICCSkwDQYJKoZIhvcNAQEFBQAwFDESMBAGA1UEAxMJTXkgSXNzdWVyMB4X
DTEyMDUxNTIwNDcxNFoXDTEyMDgxNTIwNDcxNFowUzELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAk1B
MREwDwYDVQQHEwhXZXN0Zm9yZDEPMA0GA1UEChMGUmVkSGF0MRMwEQYDVQQDEwpBZGFtIFlvdW5n
MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC7lNCEwdZMHIClZJ9f84R1tfgEjtZV2H+Nx1OR
eqeK+WYvVXSVJ61g/Vl3ponv8L/qRiqbuyP7Nfr7ogfM2OJuDOiWsyfHJSIS29NVOb5f6+oPw39Q
+fN7NSssTEr6UFz4d1mXl85iJXK+K7x5TGFQowA6po102YCj6tjesGPODQIDAQABoyQwIjAgBgNV
HSUBAf8EFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwDQYJKoZIhvcNAQEFBQADgYEAt105m7XYBugD
y+PXYq7R2XaAdyJGCBl4yq3Xz3qmfYmpP8wVTNy5j2dacuopq+W4DB0CeGo5+sYGAiRSgF8vNx6/
wMt3+EExdJO+IJl9QMRB6ooRzSMJAIH3b3jXOWln9TV6AHLHER8NWoNZq3moSYp4fO8tUVgerDKJ
7TdBP/IxggFaMIIBVgIBATAaMBQxEjAQBgNVBAMTCU15IElzc3VlcgICCSkwCQYFKw4DAhoFAKCB
lzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMCMGCSqGSIb3DQEJBDEWBBRBECaXMyVVMoW2yonU
kWwriSqs5TApBgkrBgEEAYI3EAQxHDAaMBQxEjAQBgNVBAMTCU15IElzc3VlcgICCSkwKwYLKoZI
hvcNAQkQAgsxHKAaMBQxEjAQBgNVBAMTCU15IElzc3VlcgICCSkwDQYJKoZIhvcNAQEBBQAEgYAV
UCVEsgfo3SK5p5ZF98uWgoIjmyCksS7mULJMT/ZJZJqIyTVY6AmXWCgxzKOHqrzWCansSilYAYQr
aeEgCYjX9GvSxHFmCQQzYM2buzJr5GjoPZJ0osOulUzWX8Nzq5Y51DAcWtU8c+06Ezbu5q5YjBno
2fTEWwYcemr9m/SA7AAAAAAAAA==

The break is due to how it is displayed in the browser, but that is really one long stream of characters. The value can be sent just like the current tokens, in the -X-Auth-Token header. Now a remote service can validate the token by reversing the Base64 ENCODING AND using cmsutil or the corresponding APIs.

cat auth_token.p7s.base64  | base64 -d |  cmsutil  -D -i auth_token.p7s -d alias/

There are still a few wrinkles to iron out.

The token is a little longer than it needs to be, due to the certificate being embedded. For Keystone, remote systems would be better off fetching the certificate once from the Keystone server, and just matching the serial number in the CMS token.
The current scheme of using the token in the URL would probably not work very well with the long Base64 encoding above, but that system has other known issues, and is likely to be replaced shortly with a scheme that will instead put the token into the body of the document. However, even that step will be unnecessary with certificate based verification.
Signing documents from Python currently requires calling out to additional processes. The Python-NSS maintainer is aware of the issue, and is looking into making a Python-appropriate set of bindings for the CMS calls in Python-NSS.
Since there is no revocation of the tokens, their lifespan should be kept short. 10-30 minutes is probably appropriate. The default value will require some consensus
Adding roles for a user will require getting an additional token. The old token will still be valid,but will not allow the user to do any actions that require the new role.
The code that checks roles does not currently know about the token. It will require a small amount of code changes to make sure that the token is available to this code.
While this scheme is backwards compatible with the current auth scheme, the reverse is not true. Short of checking the length of the token, there is no way to confirm that a token is a cryptographically signed document as opposed to the alpha-numeric cookie in current usage. One approach for transition may be to test reading the document, and, upon failure, fall back to the online protocol.

Adam Young: Generating a Signing Cert using certutil

2012-05-16T13:53:45+00:00

Imagine a locked room with a big window. If I am the only person with a key to room, and I tape a poster up inside the window, everyone can read it, and everyone can state with a pretty high degree of certainty that I was the person that I put up the poster. This is analogy to how you can use PKI to sign a document.

In order for the message signature to be verifiable, we generate a pair of keys, one that is kept private, and one that is made public. Data encrypted with the private key can then be decrypted with only the corresponding public key. So, to sign a message, it is encrypted with the private key.

There are ways to make this more efficient, such as signing a hash of the message, but the principal is the same.

I am going to use the same set of cryptographic tools that Mozilla provides for securing web traffic. These tools fall under then name Network Security Services or NSS for short.

The first step is to provide a Certificate Authority (CA) Certificate. This is a certificate used to sign other certificates. This is actually supposed to be part of a chain. In the browser, there are a list of CA certs that are accepted by default. For our purposes here, I am going to self sign one. Figuring out how to set this up for your organization has been left as an exercise to the reader.

We need a place to put the certificate. For NSS, this is called an NSS database. I am going to create one in a directory I call alias, because that is the name of the NSS database used in Apache HTTPD. To generate:

mkdir alias
certutil -N -d ./alias/

Now create a self-signed CA certificate. Type the command:

certutil -S -s "CN=My Issuer" -n myissuer -x -t "C,C,C" -1 -2 -5 -m 1234 -d alias/

You will be prompted to type. This is used to generate entropy, or randomness, for the underlying cryptography.

Then you will be prompted to select aspects of the certificate. A menu of options like this:

		0 - Digital Signature
		1 - Non-repudiation
		2 - Key encipherment
		3 - Data encipherment
		4 - Key agreement
		5 - Cert signing key
		6 - CRL signing key
		Other to finish

Type each number in order. 0 1 2 3 4 5 6. The menu will reappear after each.

Yes, it is annoying. I didn’t write the tool.

then type any number to finish

So the number 9 works.

 9
Is this a critical extension [y/N]?
y
Is this a CA certificate [y/N]?
y
Enter the path length constraint, enter to skip [<0 for unlimited path]: >
Is this a critical extension [y/N]?
y

Not done yet: Next menu.

		0 - SSL Client
		1 - SSL Server
		2 - S/MIME
		3 - Object Signing
		4 - Reserved for future use
		5 - SSL CA
		6 - S/MIME CA
		7 - Object Signing CA
		Other to finish

For this we want 5 6 7 then again pick 9 to exit.

 > 9
Is this a critical extension [y/N]?
y

The security conscious folks out there are squirming in their seats reading this, because a self-signed CA cert is BAD under most circumstances. However, this is proof-of-concept type stuff. You always need to get a certificate signed by a CA…this is just the simple way to do it for development.

Now that we have a CA cert, we need to generate a Key. With NSS, you can generate the Key and the certificate signing request in one step:

 certutil -R -s "CN=Adam Young, O=RedHat , L=Westford, ST=MA, C=US" -p "617-555-1212" -o mycert.req -d alias

You see the same entropy generation prompt as before.

You can list the keys using:

certutil -K -d ./alias/

Which produces output along the lines of:

certutil: Checking token "NSS Certificate DB" in slot "NSS User Private Key and Certificate Services"
< 0> rsa      99f6d153a007f8fb2d79312d454749eb92e4db99   NSS Certificate DB:myissuer
< 1> rsa      b8472a65af1c2da900fb0eb953d9c278d615a580   NSS Certificate DB:ayoung

Note that there is one in there for the CA certificate we produced before.

To sign the key run the following:

 certutil -C -m 2345 -i mycert.req -o mycert.crt -c myissuer -d ./alias/ -6

Here is the menu you are presented:

		0 - Server Auth
		1 - Client Auth
		2 - Code Signing
		3 - Email Protection
		4 - Timestamp
		5 - OCSP Responder
		6 - Step-up
		Other to finish

The import options are 1 and 3, as we are going to use the same mechanism as we would use to sign email. The private and public keys are held in the NSS database. OK, we finally have a useful certificate and key pair that we can use to sign a document. To Sign auth_token.json run:

cmsutil -S -d alias -N ayoung -i signme.txt -o signed.p7s

The signed message is put into signed.p7s. The file extension alludes to the PKCS 7 standard that CMS grew out of.

Adam Young: The Path to Kerberos over Port 443

2012-05-12T01:14:27+00:00

While Kerberos’ reputation as a Single Sign On solution is quite strong, its adoption outside the corporate VPN has been limited. One reason is that many host providers block port 88 traffic in the firewalls. What would it take to make Kerberos a viable solution in a web-only constrained situation?

Kerberos communicates over port 88 in order to secure tickets that will be used for authentication and (to a limited degree) authorization on other servers. This communication is done using the Kerberos wire protocols. First the user requests a ticket granting ticket (TGT). Later, the user will use that TGT to get a ticket specific to the service they are trying to talk to.

The connection to get the TGT is a two way street. There are multiple messages and back and forth as both sides performs steps necessary to prove to the other that they are indeed, who they claim to be. This cannot be done over straight HTTP without serious reworking, but it can be done using a techonology called websockets. With websockets, the connection between client and server remains open, and HTTP becomes a tunneling protocol for TCP.

Thus, the two things we need to do to get a TGT are:

Place the Key Distribution Center (KDC) behind a websockets Proxy.
Create a modified version of the kinit program that can talk websockets, or build a client side proxy.

There are other approaches, of course. FreeIPA can request a TGT on the server on behalf of the user. The user could download this TGT, and a Browser plugin could even stick it into the Kerberos Credentials Cache. But this bypasses the Kerberos ideal of the users password never crossing the wire.

We could write the kinit code into the browser itself, using either a native extension or Javascript, but it is a complicated enough of a protocol that forking from the C code would be a hefty maintenance effort.

The second step is trickier: getting the service ticket. This action is performed for the user automatically when visiting a web site that is protected by, for example, mod_auth_krb. The web server responds to a request with a 401 and enough information that the browser knows to try Kerberos…by way of two wrapper libraries called SASL and GSSAPI in turn. Unfortunately, this is a pipeline that is pretty much welded shut: without modifying either the browser or the Kerberos libraries, there is no way to automatically request and inject a service ticket on behalf of the user.

It would be possible for the user to do it explicitly, though. That might be an OK stop-gap measure. Again, a custom client of some sort could fetch the service ticket and push it into the Kerberos credential cache.

I think the most straight forward path would be to :

Extend the Kerberos libraries to be able to talk Web Sockets as a tunnel for the Kerberos wire protocol.
Allow a krb5.conf option that will specify that the KDC is reachable via websockets. This would be something along the lines of an krb5.conf line

kdc = wss://kerberos.younglogic.com/kdc

This value should also be available as a SRV record out of DNS:

NAME: _kerberos._wss

TYPE: SRV:

VALUE:wss://kerberos.younglogic.com/kdc

As a simple proof of concept, a websocket proxy can run on the client, listening on localhost:88 and talking via Websockets to the KDC. Then the krb5.conf file can point to the local proxy instead of the KDC Websocket proxy.

Websockets is a simple enough protocol that writing it into the Kerberos code base should not be prohibitive. If desired, it could be done as a separate shared object for the general consumption of the system.

It is not necessary to run the TGT fetching code over wss, the SSL version of web sockets, as the handshake already sets up encryption. But there is no drawback to running the whole thing over SSL and it will mask any KDC traffice that is not encrypted.

An additional advantage is that now kpasswd can be run on the same port as the rest of the KDC based services, just on a different URL.

Since Websockets is supported by all the major browsers, making browser plugins to communicate with the KDC is viable.

There might well be other issues of scale: protecting against DOS attacks and the like, but there is a path forward to a secure WebSSO.

Adam Young: My Openstack Tasks

2012-05-03T02:15:22+00:00

Now that Folsom development has started in earnest, I figured I’d follow Russell‘s example and write down a bit of my plan for work in the next couple of months.

To date, my involvement with Openstack has focused primarily on Keystone. Using that as a starting point, I want to continue it in two directions: deeper work on the identity management side, and expending HTTPD support beyond Keystone.

First is working on the Public Key Infrastructure (PKI) alternative to the Keystone Token architecture. In addition to implementing that blueprint, I have agreed to work with gyee and liemmn on making sure that the PKI work and the Key based authentication they are working on fit into an understandable narrative about the options available in Openstack.

Of course, my PKI work assumes web server support for PKI, which, shortest path, is using HTTPD. There is code from that example that I need to review and commit. In order for it to be usable, I need to set up and run a proof of concept system where Glance, Nova and Horizon all use Keystone from HTTPD.

Once I’ve made that work, I need to add support to devstack for it.

A follow on set of tasks will involve HTTPD-ifying Nova and Glance. To prep to site for this work, we are trying to establish a n URL naming scheme for Openstack.

While testing the EPEL packages of Openstack, I noticed that we lacked support for the VNC viewer noVNC. I am working with Anthony Young (no relation to me) to come up with a supportable packing format that will be accepted by the Debian and Fedora packaging standards.

Longer term, I want to be able to serve the noVNC javascript from Apache HTTPD, and talk back to HTTPD as well. There are two alternatives here:

Use an Apache Websockets module and do it all in native code
Add Websockets support to mod_wsgi.

The Google code approach uses mod_python. However, mod_python is not actively maintained, so I think this code is not going to work long haul. Making it work in mod_wsgi has hurdles to overcome. This leads me to favor the native approach as of now. I have the Apache websocket module built as an RPM, and will continue toward integrating the VNC proxy in C as an additional module.

Dan Walsh: Fedora 17 New Security Feature part X - Firewalld

2012-04-25T12:37:48+00:00

FirewallD is a service daemon with a D-BUS interface that provides a dynamic managed firewall.

It will be the default firewall in Fedora 18, but will be available to run in Fedora 17.

NOTE: I was informed that this feature was supposed to be default in Fedora 17, but has been decided to wait until Fedora 18.

The problem with the previous firewall model was that it was static, you would need to basically reload the firewall rules any time you made a change, and this would break established connections. This is a real problem for virtualization (libvirt), since you might be changing your firewall often bringing up and down virtual machines. FirewallD provides a daemon that applications can talk to over DBUS, to request modifications to firewall rules.

Another nice feature would be to allow a user to have rules that control firewall rules depending on the wireless network to which they connect. For example NetworkManager could come up with a question of whether this is the Home Network, Work Network or Public Network. Firewall rules might allow Avahi to connect if you are on a Home or Work network but not a Public Network.

In the future I would like to add make FirewallD a SELinux Userpace Manager. This would allow a policy writer could to control which applications are able to manipulate firewall rules pertaining to which ports. Something like

allow cupsd_t cups_port_t:tcp_firewall { open close };

Miroslav Grepl: How do we do selinux-policy updates?

2012-04-24T22:52:31+00:00

Sometimes I get questions how we do selinux-policy updates. How does the process go?

We go through all new bugs every day in the morning. So there are two periods per day because Dan is from USA and I am from Czech Republic.

We add appropriate fixes to the selinux-policy repo on fedorahosted.org first and then we commit changes also to the selinux-policy git repo on fedoraproject.org. But this does not mean we do a new build immediately. The main reason is we want to cover as much bugs by a build as possible. So we do a new build either at the end of the day or the next day. Of course if a build is required we do it when is needed.

Also we are not able to do a new update with an each build. In this case, you can easily download new builds from koji and install them. So if you see

“Fixed in selinux-policy-<version>”

as a comment in a bug, you get a new build very soon. If not, then I have overslept and just ping me. I would like to thank all for testing/using a new builds from koji.

Dan Walsh: Fedora 17 New Security Feature part IX - File Name Transitions

2012-04-24T14:12:18+00:00

File Name Transitions were introduced to the kernel in Fedora 16 by Eric Paris.

Eric actually expected policy writers to only add a few dozen file name transition rules, well in Fedora 17 we now have nearly 100,000 rules:

sesearch -T /etc/selinux/targeted/policy/policy.27 | grep \" | wc -l
94736

Most of these rules are to make devices created in /dev and files/directories created by the unconfined/admin processes be labelled correctly. A common problem users of SELinux have seen was when an unconfined_t user creating /root/.ssh or $HOME/.ssh. Then they would place authorization content in the directory. When they tried to use the content to gain access to the system via sshd, sshd would be blocked from the directory by SELinux because the directory and its contents had the wrong label. The user needs to run restorecon -R -v /root/.ssh to fix the labels.

Before File Name Transitions the directory would be created with the label based on the label of /root, admin_home_t. But as of Fedora 16 Policy Writers write rules that say: "If the unconfined_t user creates a directory named .ssh in a directory labelled admin_home_t, it will get created as ssh_home_t."

type_transition unconfined_t admin_home_t : dir ssh_home_t ".ssh";

How is this a security feature?

I explained in a previous blog, there are three ways content gets labeled within a directory. The File Transition rule is a mechanism the policy writer has used since SELinux was first developed to create content within a directory with a different label then the directories label. Policy writers wrote rules that said if a process running as NetworkManager_t created a file in a directory labeled etc_t it would be labeled net_conf_t.

type_transition NetworkManager_t etc_t : file net_conf_t;

Or if a process running as mozilla_t created a directory in a directory labeled user_home_dir_t, it would get created as mozilla_home_t.

type_transition mozilla_t user_home_dir_t : dir mozilla_home_t;

But this is not very fine grained control. A hacked NetworkManager could create any file in a any directory labeled etc_t, if it did not exist. If /etc/passwd did not exist for some reason SELinux would not block a confined NetworkManager from creating its own /etc/passwd. A hacked firefox running as mozilla_t would not be blocked from creating a missing $HOME/.ssh directory.

With File Name Transition rules, policy writers can now specify the file name. Meaning we can writer finer grained control. We can say NetworkManager can only create the "resolv.conf" file in a directory labeled etc_t or a confined firefox can only create the .mozilla directory in a users home directory

As an example of this the Thumbnail confinement added in Fedora 17 has:

type_transition thumb_t user_home_dir_t : file thumb_home_t "missfont.log";
type_transition thumb_t user_home_dir_t : dir thumb_home_t ".thumbnails";
type_transition thumb_t user_home_dir_t : dir gstreamer_home_t ".gstreamer-12";
type_transition thumb_t user_home_dir_t : dir gstreamer_home_t ".gstreamer-10";
type_transition thumb_t user_home_dir_t : dir gstreamer_home_t ".gstreamer-0.10";
type_transition thumb_t user_home_dir_t : dir gstreamer_home_t ".gstreamer-0.12";

Which means thumbnailers running as thumb_t can only create a file labelled missfont.log or directories labeled .thumbnails or .gstreamer-* in the home directory.

Nice job Eric, you increased the Security of SELinux and made it easier to use at the same time!

Adam Young: Array of Parameter Names in Java

2012-04-09T01:44:13+00:00

My last post suggested an extension to the Java language that I think will be quite helpful. Until such a feature exists, we can fake it by using annotations.

I created an annotation with a processor that creates a new class, one the contains a single static instance of an array of the parameter names from the constructor.

All code on this page released under the same license as the OpenJDK Libraries: GPL with the classpath exception.

First, the annotation itself.

package com.younglogic.annote;

import java.lang.annotation.ElementType;
import java.lang.annotation.Retention;
import java.lang.annotation.RetentionPolicy;
import java.lang.annotation.Target;

@Target(ElementType.CONSTRUCTOR)
@Retention(RetentionPolicy.RUNTIME)
public @interface NamedParameters {

}

Next the annotation processor. This uses the javac API, which really should become part of the Base Java platform. In order to compile I added /usr/lib/jvm/java-1.7.0/lib/tools.jar to the classpath.

package com.younglogic.annote;

import java.io.BufferedWriter;
import java.io.IOException;
import java.util.Set;

import javax.annotation.processing.AbstractProcessor;
import javax.annotation.processing.RoundEnvironment;
import javax.annotation.processing.SupportedAnnotationTypes;
import javax.annotation.processing.SupportedSourceVersion;
import javax.lang.model.SourceVersion;
import javax.lang.model.element.Element;
import javax.lang.model.element.PackageElement;
import javax.lang.model.element.TypeElement;
import javax.tools.JavaFileObject;

import com.sun.tools.javac.code.Symbol.ClassSymbol;
import com.sun.tools.javac.code.Symbol.MethodSymbol;
import com.sun.tools.javac.code.Symbol.VarSymbol;

@SupportedAnnotationTypes(value = { "com.younglogic.annote.NamedParameters" })
@SupportedSourceVersion(SourceVersion.RELEASE_7)
public class NamedParametersAnnotationProcessor extends AbstractProcessor {

	@Override
	public boolean process(Set annotations,
			RoundEnvironment roundEnv) {
		for (TypeElement element : annotations) {
			for (Element constructor : roundEnv
					.getElementsAnnotatedWith(element)) {

				ClassSymbol classSymbol = (ClassSymbol) constructor
						.getEnclosingElement();
				PackageElement packageElement = (PackageElement) classSymbol
						.getEnclosingElement();

				JavaFileObject jfo;
				try {
					jfo = processingEnv.getFiler().createSourceFile(
							classSymbol.getQualifiedName() + "ParameterNames");
					BufferedWriter bw = new BufferedWriter(jfo.openWriter());
					bw.append("package ");
					bw.append(packageElement.getQualifiedName());
					bw.append(";");
					bw.newLine();
					bw.newLine();
					bw.append("public class " + classSymbol.getSimpleName()
							+ "ParameterNames {");
					bw.newLine();
					bw.append("    static String[] instance = {");
					MethodSymbol symbol = (MethodSymbol) constructor;
					int i = 0;
					for (VarSymbol param : symbol.getParameters()) {
						if (i++ > 0) {
							bw.append(",");
						}
						bw.newLine();
						bw.append("            \"" + param.name + "\"");
					}
					bw.newLine();
					bw.append("        };");
					bw.newLine();
					bw.append("    }");
					bw.newLine();
					bw.close();
				} catch (IOException e) {
					// TODO Auto-generated catch block
					e.printStackTrace();
				}

			}

		}
		return true;
	}
}

A sample class that uses this annotation. Note that this class is immutable.

package com.younglogic.annotetest;

import com.younglogic.annote.NamedParameters;

public class SampleClass {

	final String s1;
	final String s2;
	final Integer i1;

	@NamedParameters
	public SampleClass(String s1, String s2, Integer i1) {
		super();
		this.s1 = s1;
		this.s2 = s2;
		this.i1 = i1;
	}

	@Override
	public String toString() {

		return "SampleClass values are: s1=" + s1 + ", s2=" + s2 + ", i1=" + i1.toString();
	}
}

Now add some parameters to the compiler.

-processor is the processor we want to explicitly call
-processorpath tells it where to find the new annotation.
-s tells it where to put the generated code

 javac -cp ../NamedParameters/bin/  -processorpath ../NamedParameters/bin/ -s /tmp/generated/ -processor com.younglogic.annote.NamedParametersAnnotationProcessor   src/com/younglogic/annotetest/SampleClass.java

This will generate the source file: /tmp/generated/com/younglogic/annotetest/SampleClassParameterNames.java

package com.younglogic.annotetest;

public class SampleClassParameterNames {
    public static String[] instance = {
            "s1",
            "s2",
            "i1",
            "i2"
        };
    }

And compile it to /tmp/generated/com/younglogic/annotetest/SampleClassParameterNames.class

We can use that information to create new instances. I have a file SampleClass.properties with the values I want to use to create a new instance.

i1=5
i2=10
s1="first"
s2="next"

Read it in and populate a new instance dynamically:

package com.younglogic.annotetest;

import java.io.IOException;
import java.io.InputStream;
import java.lang.reflect.Constructor;
import java.lang.reflect.InvocationTargetException;
import java.util.Properties;

public class UseParamNames {

	public static void main(String[] args) throws IOException,
			InstantiationException, IllegalAccessException,
			IllegalArgumentException, InvocationTargetException, NoSuchMethodException, SecurityException {
		Properties properties = new Properties();

		InputStream instream = UseParamNames.class
				.getResourceAsStream("SampleClass.properties");
		properties.load(instream);

		Constructor c = getConstructor();

		Object[] initargs = new Object[SampleClassParameterNames.instance.length];
		int i = 0;
		for (String name : SampleClassParameterNames.instance) {
			Class[] argTypes = { String.class };

			String strvalue = properties.getProperty(name);
			String[] paramArgs = new String[1];
			paramArgs[0] = strvalue;

			initargs[i] = c.getParameterTypes()[i].getConstructor(argTypes)
					.newInstance(paramArgs);
			i++;

		}

		Object newInstance = c.newInstance(initargs);

		System.out.println(newInstance.toString());
	}

	private static Constructor getConstructor() {
		for (Constructor c : SampleClass.class.getConstructors()) {
			if (c.getAnnotations().length > 0) {
				return c;
			}

		}
		return null;
	}
}

Which, when run, produces the output:

SampleClass values are: s1="first", s2="next", i1=5

Adam Young: Parameter Names in Java

2012-04-05T17:13:32+00:00

There is a very small feature that could be added to Java in order to improve it significantly: Add names to the Parameter object in the Reflection API.

When creating a new Object in Java, the parameter list for the constructor or factory provides the contract. Unfortunately, a key element of this contract is missing at run rime when it is needed most. If a constructor takes multiple values of the same type, the only way to distinguish between them are the names of the parameters. For example, the JDBC API to create a new connection takes three parameters: the username and password to use for the connection authentication and authorization, and the URL of the Datasource. However, all three values are strings. In order to distinguish between them, the user needs to know the order of the parameters: is it URL first or UserID first?

Building a new object from a persisted dictionary is common enough that there is a different API as well that takes a Properties object. This variation loses all documentation about what is required to authenticate a connection: username and password. Since the format of the URL is also Driver specific, the user is thus relegated to digging through the documentation to figure out how to correctly create a Connection. However, reading the documentation is not an option for an automated tool.

What Java lacks is a standardized and automated way to map a key-value pair collection to a function. The mechanism should look like this.

private static Object createInstanceFromProperties(Method method, Properties properties)
throws InstantiationException, IllegalAccessException,
       InvocationTargetException, NoSuchMethodException {
    //This is the new call.
    String[] paramNames = method.getParameterNames();
    //Spacing is due to limitation of web display for angle bracketed expressions.
    Class < ? > [] argsTypes = method.getParameterTypes();

    Object arguments[] = new Object[argsTypes.length];
    for (int i = 0; i < paramNames.length; i += 1) {
        String val = properties.getProperty(paramNames[i]);
        if (argsTypes[i] == java.lang.String.class) {
	    arguments[i] = val;
        }else{
            arguments[i] = argsTypes[i].getConstructor(java.lang.String.class).newInstance(val);
	}
    }
    return method.invoke(null, arguments);
}

A simple variation can work with a Constructor object instead of a Method object. One assumption from the above code that should be explicit is that the framework using this call has enough information to determine which variation of the Method or Constructor to find.

I wouldn't ordinarily implement an API like this as Parallel arrays, but in this case, it is the least impact on the existing API. There is no "Parameter" object in the existing API.

Since existing compiled classes would not have provided the array of names, one version of Java should be provided as a transitory step which will allow the JDK to return a Null if the class does not provide the appropriate strings.

Adam Young: Openstack Keystone in HTTPD

2012-04-04T16:31:02+00:00

After calling for Keystone to migrate to HTTPD, several people asked me if I would show how this can be done. Here are the steps.

Update: in testing keystone, you need to change the username from demo to admin as per the export lines near the bottom of this page.

A prerequisite is to set up NSS HTTPD SSL support. We can use it in conjunction with Keystone to provide encrypted access for authentication and authorization.

I created a file to enable wsgi:

/var/www/cgi-bin/keystone/keystone.py

import os
from keystone import config
from paste import deploy
from keystone.common import logging
from keystone.common import utils
from keystone.common import wsgi

LOG = logging.getLogger(__name__)
CONF = config.CONF
config_files = ['/opt/stack/keystone/etc/keystone.conf']
CONF(config_files=config_files)

conf = CONF.config_file[0]
#name = 'admin'
name = os.path.basename(__file__)

if CONF.debug:
    CONF.log_opt_values(logging.getLogger(CONF.prog), logging.DEBUG)

options = deploy.appconfig('config:%s' % CONF.config_file[0])

application = deploy.loadapp('config:%s' % conf, name=name)

And I hardlinked it:

cd /var/www/cgi-bin/keystone/
ln  keystone.py admin
ln  keystone.py main

This is based on a Fedora devstack deployment, which checks out the code in /opt/stack/keystone. I ran against master from git, which as of this writing should be the same as the next Essex RC. I ran python setup.py install with this, which gave me the installed egg in

/usr/lib/python2.7/site-packages/keystone-2012.2-py2.7.egg.

Since eggs deployed this way are part of the default Python path, it is usable by WSGI applications in Apache.

To run against the Fedora RPMs, the difference would be to read in the config file /etc/keystone/keystone.conf instead.

I’ve changed /etc/httpd/conf.d/keystone.conf to

WSGIScriptAlias /main /var/www/cgi-bin/keystone/main
WSGIScriptAlias /admin /var/www/cgi-bin/keystone/admin

<location>
   NSSRequireSSL
</location>

<location>
   NSSRequireSSL
</location>

and restarted httpd. To test:

The most straightforward way to test Keystone is via the command line interface (CLI). When running via devstack, the normal approach is to source the environment file:

. openrc

which pulls in the localrc. This sets many values, including the URL to be used when the Keystone CLI talks to the server: OS_AUTH_URL. Typically this is set as some variation on the local hostname and the port 5000. It also sets the username to demo To test HTTPD, change this to:

export OS_AUTH_URL=https://$HOSTNAME/admin/v2.0
export OS_USERNAME=admin

However, running the command line client gave an error:

[ayoung@ayoungstack devstack]$ keystone user-list
No handlers could be found for logger "keystoneclient.client"
Invalid OpenStack Identity credentials

Looking in the access log, I saw the token request was succeeding (returned 200) but the second request failed with unauthorized (401).

One difference between Eventlet and the Fedora build of HTTPD is that each request in HTTPD is handled by a separate process. This is called prefork, and you can test a given install by running

[ayoung@ayoung keystone]$ httpd -l
Compiled in modules:
  core.c
  prefork.c
  http_core.c
  mod_so.c

To see the built in modules. The default way that Keystone stores Tokens is by using a key value pair storage. You see this in the keystone.conf file.

[token]
driver = keystone.token.backends.kvs.Token

By changing this to the SQL store, the tokens are now accessable by other processes, including the ones that will handle follow on requests to Keystone.

[token]
driver = keystone.token.backends.sql.Token

And now the keystone CLI works:

[ayoung@ayoungstack devstack]$ keystone user-list
+----------------------------------+---------+--------------------+--------+
|                id                | enabled |       email        |  name  |
+----------------------------------+---------+--------------------+--------+
| 6d42897928974d469a4223302e6bae4a | True    | admin@example.com  | admin  |
| 72f2941c7e3e40b292d50bd8b1662899 | True    | demo@example.com   | demo   |
| 92556c2d36de4f46a0a9916d96d2e793 | True    | glance@example.com | glance |
| e452d5f649ed489c8b84b8192e781263 | True    | nova@example.com   | nova   |
+----------------------------------+---------+--------------------+--------+

Adam Young: Client Certificates with mod_nss

2012-03-30T21:22:23+00:00

Once server side certificates have been set up, setting up client side certificates requires some additional configuration, especially if you want to use them as the source of identity in your applications.

First, the application needs the additional directive in its /etc/httpd/conf.d specific file.

   NSSVerifyClient require

Did that work for you? NO…me neither…

OK, so actually, it was slightly more involved. First, I had to figure out how to turn on NSS debugging. That is done by editing the file

/etc/httpd/conf.d/nss.conf

and setting the value for

LogLevel debug

Once that worked, I saw messages in /var/log/httpd/error_log that looked like:

[Fri Mar 30 11:43:54 2012] [debug] nss_engine_kernel.c(309): Changed client verification type will force renegotiation
[Fri Mar 30 11:43:54 2012] [info] Requesting connection re-negotiation
[Fri Mar 30 11:43:54 2012] [debug] nss_engine_kernel.c(404): Performing full renegotiation: complete handshake protocol
[Fri Mar 30 11:43:54 2012] [debug] nss_engine_kernel.c(418): Re-negotation request failed: returned error -12176

So I enabled renegotiation. Again, editing /etc/httpd/conf.d/nss.conf

NSSRenegotiation on
NSSRequireSafeNegotiation on

And then client side certs worked for me. They probably won’t work for you, though.

I cheated.

In between, I set up a Dogtag PKI instance, generated a new server side certificate, a client side certificate for my browser, and installed the CA and Server side certificate in my web server.

I don’t think all of that was necessary.

A variation would have been to generate a client side certificate and sign it with the self-sign CA key that my web server was already using. The bottom line is that the browser and the server need to both trust the CAs used for the client and server certs.

Ok, so we’ve established a secure channel. This doesn’t mean much if we don’t know who the user is at the application level. The NSS layer follows the SSL approach of using the option: FakeBasicAuth to pass information from the Certificate through to the application. I uncommented the line:

NSSOptions +FakeBasicAuth +ExportCertData +CompatEnvVars +StrictRequire

You also need to tell NSS which value from the certificate should be passed as the user. In my case, it is the Subject:uid value, so I configured mine as:

NSSUserName SSL_CLIENT_S_DN_UID

The overall difference in the nss.conf file is:

--- /etc/httpd/conf.d/nss.conf.orig	2012-03-29 12:59:06.319470425 -0400
+++ /etc/httpd/conf.d/nss.conf	2012-03-30 16:21:24.836124822 -0400
@@ -17,7 +17,7 @@
 # Note: Configurations that use IPv6 but not IPv4-mapped addresses need two
 #       Listen directives: "Listen [::]:8443" and "Listen 0.0.0.0:443"
 #
-Listen 8443
+Listen 443

 ##
 ##  SSL Global Context
@@ -71,17 +71,17 @@
 #
 # Only renegotiate if the peer's hello bears the TLS renegotiation_info
 # extension. Default off.
-NSSRenegotiation off
+NSSRenegotiation on

 # Peer must send Signaling Cipher Suite Value (SCSV) or
 # Renegotiation Info (RI) extension in ALL handshakes.  Default: off
-NSSRequireSafeNegotiation off
+NSSRequireSafeNegotiation on

 ##
 ## SSL Virtual Host Context
 ##

-<virtualhost _default_:8443="_default_:8443">
+<virtualhost _default_:443="_default_:443">

 #   General setup for the virtual host
 #DocumentRoot "/etc/httpd/htdocs"
@@ -92,7 +92,7 @@
 # LogLevel is not inherited from httpd.conf.
 ErrorLog /etc/httpd/logs/error_log
 TransferLog /etc/httpd/logs/access_log
-LogLevel warn
+LogLevel debug

 #   SSL Engine Switch:
 #   Enable/Disable SSL for this virtual host.
@@ -198,7 +198,8 @@
 #   o OptRenegotiate:
 #     This enables optimized SSL connection renegotiation handling when SSL
 #     directives are used in per-directory context.
-#NSSOptions +FakeBasicAuth +ExportCertData +CompatEnvVars +StrictRequire
+NSSOptions +FakeBasicAuth +ExportCertData +CompatEnvVars +StrictRequire
+NSSUserName SSL_CLIENT_S_DN_UID
 <files>
     NSSOptions +StdEnvVars
 </files>

Now a little bit of Python/WSGI specifics
For my WSGI application, I add in a value that says “pass on the authentication info to the application”

WSGIPassAuthorization On

Then the WSGI app can access the value via:

class Application(BaseApplication):
    @webob.dec.wsgify
    def __call__(self, req):
    context['remote_user'] = req.environ.get('REMOTE_USER')

Here is what my file /etc/httpd/conf.d/keystone.conf looks like to protect the suburl “main”:

WSGIScriptAlias /main /var/www/wsgi/httpdmain.py
WSGIScriptAlias /admin /var/www/wsgi/httpdadmin.py

< Location "/main" >
   NSSRequireSSL
   NSSVerifyClient require
   WSGIPassAuthorization On
< / Location >

Adam Young: Setting up SSL with NSS is easier than you think

2012-03-30T17:50:30+00:00

At least, it is on Fedora 16

sudo yum install mod_nss

/etc/httpd/alias/ is populated already with ca and server cert self signed
/etc/httpd/conf.d/nss.conf already exists
change 8443 to 443 in two places

--- /etc/httpd/conf.d/nss.conf.orig	2012-03-29 12:59:06.319470425 -0400
+++ /etc/httpd/conf.d/nss.conf	2012-03-29 12:19:38.862721465 -0400
@@ -17,7 +17,7 @@
 # Note: Configurations that use IPv6 but not IPv4-mapped addresses need two
 #       Listen directives: "Listen [::]:8443" and "Listen 0.0.0.0:443"
 #
-Listen 8443
+Listen 443

 ##
 ##  SSL Global Context
@@ -81,7 +81,7 @@
 ## SSL Virtual Host Context
 ##

-<virtualhost _default_:8443="_default_:8443">
+<virtualhost _default_:443="_default_:443">

 #   General setup for the virtual host
 #DocumentRoot "/etc/httpd/htdocs"

Make sure your firewall is open on the HTTPS port. Add the following line in /etc/sysconfig/iptables

-A INPUT -m state --state NEW -m tcp -p tcp --dport 443 -j ACCEPT

before the statement

-A INPUT -j REJECT --reject-with icmp-host-prohibited

and restart the services

sudo systemctl restart iptables.service
sudo systemctl restart httpd.service

The documentation provides a lot more detail. Almost all of these steps are performed by the RPM install on F16 and later.

Dan Walsh: runuser versus su

2012-03-28T12:40:09+00:00

Many years ago, we noticed SELinux having problems with the su command. Many confined domains were using su to switch user from root to some non privileged user. But this would generate lots of bogus SELinux errors such as:

Domain X_t wants to getattr on the fingerprint device or look at the pid file of the Smart Card reader.

su using the pam_stack was the cause of these errors. Depending on which pam_modules you had in the /etc/pam.d/su configuration, certain access would be checked. Services using su do not want/need these side effects of using the pam stack. SELinux policy writers do not want to allow the access or add dontaudit rules all over the place.

In order to fix this, we built a new application called runuser. runuser is actually built from the su.c source code. You just define the RUNUSER constant when compiling su.c. Basically runuser is just the su command with the pam stack removed as well as verifying the command is running as root, not setuid.

Whenever an service is running as root and wants to change UID using the shell it should use runuser.

When you are logged in to a shell as a user and want to become root, you should use su. (Or better yet sudo)

Adam Young: Shared Nothing Diskless Boot

2012-03-28T01:07:15+00:00

It is possible to run a computer with no persistent storage for its root file system other than a single image downloaded an held in RAM. The computer does not needs a local disk. The computer also does not need a SAN or NAS device for the Root File system.

There are numerous uses for this style of booting. A short list:

Debugging the installation processes of software packages
Running computationally intensive tasks on a large array of nodes
Inventorying the hardware no new servers
Deploying a light management framework for virtualization hypervisors

Here is a brief overview of the pieces needed to set this up for testing purposes on a workstation running KVM.

Configure a local network for PXE traffic
Install a machine to server as the PXE server
Install and Configure DHCPD
Install and Configure TFTP
create a rootfs
Install HTTPD
get a boot image
PXE Boot a Blank VM

The first piece is done on the workstation itself, and is just overhead for doing this ins a completely virtualized environment. This is the analogue of using a private secured backbone for administrative backbone when using physical machines. Configuring the network used to take editing the Network XML file, but now you can deselect the DHCP checkbox in virt-manager when creating a new network. Here is what mine generated in /var/lib/libvirt/network/nodhcp.xml.

<network>
  <name>nodhcp</name>
  <uuid>ec819c42-b4b0-1577-363e-1c5918a3ee29</uuid>
  <bridge delay="0" name="virbr2" stp="on">
  <mac address="52:54:00:FC:2F:62">
  <ip address="172.33.22.1" netmask="255.255.255.0">
  </ip>
</network>

You could save that in /root and do

 sudo virsh network-create /root/nodhcp.xml

This one has a bridge defined, which is probably not what you would want for your server, as this network should not see the outside world. Still the device is useful if you want to run wireshark on it to debug booting issues.

Create the server as a VM, and provide it Network interface on both a publicly accessible as well as the Private network defined above. Install Fedora (I used F17 Alpha) as per normal.

Install the Server pieces

yum install syslinux tftp-server  dhcp  dracut-network  httpd httpd-tools apr apr-util apr-util-lda

Configure DHCPD by editing /etc/dhcp/dhcpd.conf

allow booting;
allow bootp;

subnet 172.22.33.0 netmask 255.255.255.0 {
        option routers                  172.22.33.1;
        option subnet-mask              255.255.255.0;
        option domain-search              "younglogic.com";
        option domain-name-servers       172.22.33.1;
        option time-offset              -18000;     # Eastern Standard Time
        range 172.22.33.100 172.22.33.140;
}

class "pxeclients" {
   match if substring(option vendor-class-identifier, 0, 9) = "PXEClient";
   next-server server-ip;
   filename "pxelinux.0";

Set up TFTP.

edit /etc/xinetd.d/tftp and set

	disable			= no

Copy over the Kernel

cp /boot/vmlinuz-3.3.0-0.rc6.git0.2.fc17.x86_64 /var/lib/tftpboot/vmlinuz-3.3.0-0.rc6.git0.2.fc17.x86_64

Dracut is a great tool for people that need to control the boot procedure of their machines. It has a module called Livenet that we use to specifying that the root file system should be downloaded an unpacked in a directory. In order for that to work, we need the dracut-network package specified on the yum line above. THen, we need to generate a new initial ramdisk (initrd) with the livenet module enabled.

dracut -v  --force --add "livenet"  /var/lib/tftpboot/initramfs-kernel-3.3.0-0.rc6.git0.2.fc17.x86_64.img 3.3.0-0.rc6.git0.2.fc17.x86_64

Syslinux is our boot loader. Syslinux is more than a tool to run an installer (although it does that quite well). Here, it is a program that is configured much as for a kickstart, but it will instead switch to running the kernel instead of Anaconda.

cp  /usr/share/syslinux/pxelinux.0 /var/lib/tftpboot
mkdir /var/lib/tftpboot/pxelinux.cfg/

The configuration for syslinux is in /var/lib/tftpboot/pxelinux.cfg/default and looks like this

default f17

serial --unit=0 --speed=9600
terminal --timeout=5 serial console

label f17
  kernel vmlinuz-3.3.0-0.rc6.git0.2.fc17.x86_64
  append initrd=initramfs-kernel-3.3.0-0.rc6.git0.2.fc17.x86_64.img console=tty0  rd.shell rd.debug root=live:http://172.22.33.2/squashfs.img   rw

The most interesting value here is root=live:http://172.22.33.2/squashfs.img which is what activates the Dracut module in the initrd to download the rootfs via http and expand it into the new root directory.

I know that a couple of these values are incorrect, and I will update when I have them straight, but this will work.

Once everything is in place, you need to make sure SELinux is happy. Otherwise, the Kernel will deny the tftp network service access to the files it needs to serve. Of course, you could always disable SELinux, but lets try to do things right To see what the SELinux context for the newly copied file is:

ls -Z /var/lib/tftpboot/vmlinuz-3.3.0-0.rc6.git0.2.fc17.x86_64
rwxr-xr-x. root root unconfined_u:object_r:tftpdir_rw_t:s0 /var/lib/tftpboot/vmlinuz-3.3.0-0.rc6.git0.2.fc17.x86_64

To see what it should be:

[root@f17stack ~]# matchpathcon /var/lib/tftpboot/
/var/lib/tftpboot	system_u:object_r:tftpdir_rw_t:s0

To set the whole directory to the correct context

 chcon -Rv --type=tftpdir_rw_t  --user=system_u  /var/lib/tftpboot/

There is probably a more correct way to do this, something along the lines of

restorecon -R -v /var/lib/tftpboot/

But that doesn’t seem to set the user.

At this point you can restart both services. Make sure that dhcpd runs at machine reboot as well.

/bin/systemctl enable  dhcpd.service
/bin/systemctl restart xinetd.service
/bin/systemctl restart dhcpd.service

To test that things are running correctly:

[root@f17stack tmp]# cd /tmp
[root@f17stack tmp]# getenforce
Enforcing
[root@f17stack tmp]# tftp localhost -c get initramfs-kernel-3.3.0-0.rc6.git0.2.fc17.x86_64.img
[root@f17stack tmp]# ls initramfs-kernel-3.3.0-0.rc6.git0.2.fc17.x86_64.img
initramfs-kernel-3.3.0-0.rc6.git0.2.fc17.x86_64.img

Make sure Apache is running and will run on boot:

[root@f17stack tmp]# systemctl enable  httpd.service
[root@f17stack tmp]# systemctl start httpd.service

The final step is to setup a bootable image. In this case, we use the same thing that the live CD uses, which is packaged inside of a squashfs image.

I did this on my desktop to keep from having to have too big a file on my Server VM. As it is, this is still close to a 588MB image.

sudo mount -o loop  ~/Downloads/Fedora-16-x86_64-Live-Desktop.iso /mnt
scp /mnt/LiveOS/squashfs.img root@f17stack.ayoung.boston.devel.redhat.com:/var/www/html

And again, on the server, lets check SELinux

[root@f17stack tmp]# ls -Z /var/www/html/
f16/          index.html    squashfs.img
[root@f17stack tmp]# ls -Z /var/www/html/squashfs.img
-r--r--r--. root root unconfined_u:object_r:httpd_sys_content_t:s0 /var/www/html/squashfs.img

And make SELinux Happy:

chcon -Rv --type=httpd_sys_content_t  --user=system_u  /var/www/html/

I have to admit, I had already gotten the system to relable the file by the time I tested this, I suspect upon a reboot, so this last step might not be necessary.

Now, open the firewall to let dhcp, tftp, and http traffic through. This can be done via the following rules added to /etc/sysconfig/iptables

-A INPUT -m state --state NEW -m tcp -p tcp --dport 68 -j ACCEPT
-A INPUT -m state --state NEW -m udp -p udp --dport 68 -j ACCEPT
-A INPUT -m state --state NEW -m tcp -p tcp --dport 69 -j ACCEPT
-A INPUT -m state --state NEW -m udp -p udp --dport 69 -j ACCEPT
-A INPUT -m state --state NEW -m tcp -p tcp --dport 80 -j ACCEPT

And restarting iptables:

systemctl start iptables.service

Now Boot the second VM. If all goes well, it will Get its IP address:

There will likely be a delay as it downloads the 588 install image:

And when it is done, you are at Firstboot:

Thanks to Will Woods for cluing me in about squashfs and livenet, Harald Hoyer for general Dracut help, and Ray Strode for help with debugging why my console wouldn’t echo.

Miroslav Grepl: When should you use the “optional_policy” block statement?

2012-03-23T07:28:43+00:00

After writing the blog on optional policy, I received the following question:

“Ho do I know whether I need to use the optional_policy block or not?”

When we write policy we can choose to have the policy either shipped within the base policy or as as module.

We use the modules config files to specify whether a policy is in the base or module.

We have a different modules config file for each policy type that we ship

modules-targeted.conf
modules-mls.conf
modules-minimum.conf

which contain statements like

# Layer: kernel
# Module: domain
# Required in base
#
# Core policy for domains.
#
domain = base

# Layer: system
# Module: init
#
# System initialization programs (init and init scripts).
#
init = module

What does either “base” or “module” mean? The note says

# For modular policies, modules set to “base” will be
# included in the base module. “module” will be compiled
# as individual loadable modules.

The base.pp policy module contains core policy modules which are needed for the basic confinement of your system focused on the core operating system. The base.pp module can not be removed from your policy.

But what about “module”. This is different. Theoretically these modules are all optional. Meaning you should be able to remove them from the policy if you wanted to.

You can list the modules using:

$ semodule -l

There are some exceptions for modules like miscfiles, authlogin, init,
systemd, sysnetwork. We define them as “module” in the modules-*.conf
file but they can not be removed.

Another way of looking at this would be to examine the directories in
which we ship the interfaces. We ship interface files in /usr/share/selinux/devel/include/ subdirs

system kernel roles services admin apps

Interfaces in system and kernel are core to the system, while interfaces in the other directories as optional.

Let’s say you write a policy and you need to use a rpm interface because your application execute rpm -qi. First, we need to examine that the rpm module is not a part of the base.pp policy module

$ semodule -l | grep rpm
rpm 1.12.0

Ok, I see it is not. So I will call a rpm interface with the optional_policy block.

optional_policy(`
rpm_exec(mydomain_t)
‘)

Dan Walsh: Eating my own dogfood.

2012-03-22T14:19:45+00:00

I am going on a trip tomorrow, I went to the Jet Blue web site to print my boarding pass. The Jet Blue site has what I believe is a java application running in the browser that displays your boarding pass. I pressed the "Print" button on the screen and a print dialog came up, without any printers, and the "Print" button grayed out.   I did not notice the, setroubleshoot warning in gnome 3. Figuring the print application was just broken, I decided to select print from the browser. Sadly the browser printed a blank page. I then bad mouthed Firefox/Linux printing.

Mia Culpa

I noticed that I had AVC's that looked like mozilla_plugin_t was trying to getattr on lpr_exec_t.    I put mozilla_plugin_t into permissive mode, to find out all the access required.

# semanage permissive -a mozilla_plugin_t

I went back to Jet Blue and tried to print the boarding pass again. This time the printers showed up and I was able to print my boarding pass.

Now I had AVC's that indicated mozilla_plugin_t was executing lpr_exec_t. Also lpr was connecting to the cups and gnome-keyring daemon.

Should I transition or add allow rules for mozilla_plugin_t?

As a policy writer I had to choice whether to allow mozilla_plugin_t all of these accesses or have mozilla_plugin_t transition to the lpr_t domain when it executes /usr/bin/lpr.   These decisions are key to writing good security policy. My rule of thumb is if the domain i would transition to is very powerful, I hesitate to transition. Especially if the parent application requires limited access when executing the child. For example a user can run rpm in their current domain (staff_T) to list all rpm packages, while if I allowed them to transition to the rpm_t domain, they would be allowed install rpm packages. In the mozilla_plugin_t case the advantage of transitioning to lpr_t allows me to continue to prevent mozilla plugins from talking directly to the cups server and the gnome-keyring and lpr_t is a very limited domain, so I chose to transition.

My initial policy looked like this:

policy_module(mypol, 1.0)

require {
    type mozilla_plugin_t;
}
lpd_domtrans_lpr(mozilla_plugin_t)

Now I tried to print the boarding pass again, and now I had AVC's that stated lpr_t was trying to connect to keyring.

audit2allow -R indicated that I should use:

gnome_stream_connect_gkeyringd(lpr_t)

audit2allow also showed that I was failing on Roles Based Access Control (RBAC).   Users seldom see these types of errors. They show up in the log file as SELINUX_ERR rather then AVC.

type=SELINUX_ERR msg=audit(1332420617.119:909): security_compute_sid: invalid context staff_u:staff_r:lpr_t:s0-s0:c0.c1023 for scontext=staff_u:staff_r:lpr_t:s0-s0:c0.c1023 tcontext=staff_u:staff_r:lpr_t:s0-s0:c0.c1023 tclass=unix_stream_socket

This AVC is basically saying the staff_u:staff_r:lpr_t:s0-s0:c0.c1023 is an invalid label.

Hard to tell from this error what is wrong, but luckily audit2allow translates this into:

role staff_r types lpr_t;

Since I run with the staff_r role, I had to add an RBAC rule that would allow staff_r role to reach the lpr_t type.

My final policy looks like:

policy_module(mypol, 1.0)
require {
    type mozilla_plugin_t;
    type lpr_t;
    role staff_r;
}
lpd_domtrans_lpr(mozilla_plugin_t)
role staff_r types lpr_t;
gnome_stream_connect_gkeyringd(lpr_t)

Notice how I am transitioning from mozilla_plugin_t to lpr_t. This does not mean staff_t will transition to lpr_t when running /usr/bin/lpr.
In fact, staff_t executes lpr in the staff_t domain, since the staff_t domain has the ability to connect to the cups and gnome-keyring daemons.

But when staff_t executes a firefox plugin, the plugin will transition to a locked down domain mozilla_plugin_t. When the mozilla_plugin_t plugin executes /usr/bin/lpr, the lpr command will transition to the lpr_t domain.

Printing now works well. Now I can remove the permissive flag from mozilla_plugin_t.

# semanage permissive -d mozilla_plugin_t

I have added all these rules into Fedora 17 policy, it should show up in the next policy update.

This is why I live in Rawhide, I want to find problems before users do.

Adam Young: Fedora 16 Devstack

2012-03-21T17:06:01+00:00

Devstack is a developer tool for dealing with the wide array of projects that make up openstack. The original devstack is Ubuntu specific. Russell B has been working on getting Fedora its own Devstack. Today, I’m a test subject.

Yesterday I got a Box from Spot that I gave a fresh Fedora 16 install including the yum group for Virtualization. Downloaded and installed aF16 and a F17 VM, so I know it can do the basics.

Today’s notes:

yum install git

git clone https://github.com/russellb/devstack.git

git branch --track fedora-support  remotes/origin/fedora-support

git checkout fedora-support

edit localrc (inside the git repo, it has been .gitignored) and add the line:

MESSAGING_SYSTEM=qpid

./stack.sh

Output is :

which: no lsb_release in (/usr/local/bin:/bin:/usr/bin:/usr/local/sbin:/usr/sbin:/sbin:/home/ayoung/.local/bin:/home/ayoung/bin) ./stack.sh: line 180: -q: command not found The first warning is spurious. The second Russell Fixed that by quoting

CHECK_SUDO_CMD="rpm -q sudo"

And pushed to git. fetc, rebase and now we are at:

./stack.sh


which: no lsb_release in (/usr/local/bin:/bin:/usr/bin:/usr/local/sbin:/usr/sbin:/sbin:/home/ayoung/.local/bin:/home/ayoung/bin)
sudo-1.8.3p1-2.fc16.x86_64
[sudo] password for ayoung:
eth0: error fetching interface information: Device not found

Could not determine host ip address.
Either localrc specified dhcp on eth0 or defaulted to eth0

This host doesn't have eth0, it has em1. So to fix that set add a line to localrc

HOST_IP_IFACE=em1

Ran ./stack again and:

DEBUG:openstack_dashboard.settings:Running in debug mode without debug_toolbar.
Traceback (most recent call last):
#lines removed for brevity
File "/opt/stack/horizon/horizon/decorators.py", line 29, in module
from horizon.exceptions import NotAuthorized, NotFound
File "/opt/stack/horizon/horizon/exceptions.py", line 137, in module
swiftclient.Error,

To disable that, edit localrc and add the line (note: without horizon on it)

ENABLED_SERVICES=g-api,g-reg,key,n-api,n-crt,n-obj,n-cpu,n-net,n-vol,n-sch,n-novnc,n-xvnc,n-cauth,mysql,rabbit

And the install succeeded. All processes are running in screens. You'll probably want The fine manual.

screen -x takes me to a nova command (which I accidentally kill and then rerun, as it was the last thing in bash histroy..)

 cd /opt/stack/nova && /opt/stack/nova/bin/nova-objectstore

Running Ctrl A " gives the following list of screens.

0 stack
1 g-reg
2 g-api
3 key  
4 n-api
5 n-cpu
6 n-crt
7 n-vol
8 n-net
9 n-sch
10 n-novnc
11 n-xvnc
12 n-cauth
13 n-obj

The g- screens are glance processes and the n- screens are nova processes. key is keystone.

Kill all the screens with Ctrl-a / and then rerun stack.sh to see any changes.

Dan Walsh: Solution to /myapache labeling problem from yesterday...

2012-03-20T13:30:25+00:00

Twitter's @Plaimclock tweeted me @rhatdan yester.
He pointed out that yesterdays blog on SELinux Labeling did not provide a solution to the /myapache problem.

The solution is to label /myapache and all its children with a label httpd can read.

You can figure this out by using:

man httpd_selinux
...
      httpd_sys_content_t

       - Set files with the httpd_sys_content_t type, if you want to treat the
       files as httpd sys content.

       Paths:
            /usr/share/icecast(/.*)?,                  /usr/share/htdig(/.*)?,
            /etc/htdig(/.*)?,                         /var/www/svn/conf(/.*)?,
            /usr/share/doc/ghc/html(/.*)?,       /usr/share/mythtv/data(/.*)?,
            /var/lib/htdig(/.*)?,                         /srv/gallery2(/.*)?,
            /srv/([^/]*/)?www(/.*)?,               /usr/share/ntop/html(/.*)?,
            /usr/share/mythweb(/.*)?,                /var/lib/cacti/rra(/.*)?,
            /usr/share/openca/htdocs(/.*)?,            /usr/share/selinux-pol‐
            icy[^/]*/html(/.*)?,   /usr/share/drupal.*,   /var/lib/trac(/.*)?,
            /var/www(/.*)?, /var/www/icons(/.*)?

Or

# ls -lZd /var/www/html
drwxr-xr-x. root root system_u:object_r:httpd_sys_content_t:s0 /var/www/html

You could simply put the labels in place using chcon.

chcon -R -t httpd_sys_content_t /myapache

The best solution is to tell SELinux about the label change.

# semanage fcontext -a -t httpd_sys_content_t '/myapache(/.*)?'
# restorecon -R -v /myapache

Done

Note: If you wanted to allow httpd to write to the directory you would use the httpd_sys_rw_content_t type.

Dan Walsh: SELinux Types Revisited.

2012-03-19T16:06:00+00:00

A common mistake people make with SELinux is thinking all types are the same.

I often get bugzilla's from people who first got a bug saying that httpd_t can not read some directory, say /myapache. The admin then does some limited research and discovers the chcon command. The admin then assumes if he uses the chcon command with the httpd type, it will solve his problem.

# chcon -t httpd_t /myapache
chcon: failed to change context of `/myapache' to `staff_u:object_r:httpd_t:s0': Permission denied

What, wait I am unconfined_t, why won't this be allowed.

# setenforce 0
# chcon -t httpd_t /myapache
#

Works, I guess I am all set.
# setenforce 1

Apache blows up.

Now they have AVC messages that indicate they need

allow unconfined_t httpd_t:dir relabelto;
allow httpd_t fs_t:filesystem associate;

Since the admin forced the label onto the system, other parts of SELinux start to break. Later locate runs and they get an AVC that requires

allow locate_t httpd_t:dir getattr;

What the ...

The assumption, the administrator mistakenly made, was that all types are created equally. But SELinux groups different types and then controls what "Classes" they can be assigned to. SELinux block you from assigning a type to unsupported objects.

For example SELinux has types for Files (file_type), Processes(domain), Ports (port_type), Ethernet Interfaces (netif_type), Node names (node_type), filesystems (filesystem_type) ...

Types are grouped together using the policy attribute notated above within the ().

SELinux only allows administrators to assign file_type to a filesystem_type object. This access is controlled by the associate access.

# sesearch -A -s file_type -t filesystem_type -p associate | grep file_type
   allow file_type fs_t : filesystem associate ;
...

If you want to list all file_types, execute:

seinfo -afile_type -x
   file_type
      bluetooth_conf_t
      cmirrord_exec_t
      colord_exec_t
...

I have added an setroubleshoot plugin to Fedora 17 to try to help the administrator out.

SELinux is preventing chcon from relabelto access on the directory myapache.

***** Plugin associate (99.5 confidence) suggests **************************

If you want to change the label of myapache to httpd_t, you are not allowed to since it is not a valid file type.
Then you must pick a valid file label.
Do
select a valid file type. List valid file labels by executing:
# seinfo -afile_type -x

Hope this hopes, although I agree this is a difficult concept to understand.

Adam Young: Announcing Dogtag 10.0.0 (Alpha)

2012-03-15T18:38:38+00:00

The Dogtag team is pleased to announce the availability of an Alpha Release of the Dogtag 10.0 code.

(Reposted from the pki-users mailing list)

This release contains the following features:

1. Extension of the functionality of the DRM to store and retrieve symmetric keys and passphrases,
rather than only asymmetric keys. This feature allows the DRM to be used as a secure
vault-like storage for essentially any sensitive data. The data is stored using the same
secure FIPS-compliant storage mechanism used to store PKI keys.
2. The new DRM functionality is exposed through a new REST interface, provided by the RESTEasy
framework. This provides an intuitive mechanism for writing clients to the interface. Both
Java (using the RESTEasy client proxy framework) and Python clients have been coded. The
server uses standard Java libraries to generate and parse XML or JSON input and output data.
3. Extracted authentication and authorization code from the individual servlets into a standard
Tomcat authentication realm. This realm has been configured to require client certificate
authentication, and is being used to secure the new DRM REST interface. In the future, this
authentication realm could be extended to include other kinds of authentication (such as
Kerberos). This is part of a push to refactor the code to expose the core business
functionality in the servlets, while extracting the ancillary tasks (authentication,
authorization, XML parsing and generation, etc.) and using standard methods and libraries to
accomplish these tasks.
4. Enhanced Java subsystems so that they could connect to the internal database using a
non-directory manager user, that is authenticated using client authentication. This resolves a
number of issues with LDAP operations ignoring search limits. In addition, some changes have
been made to allow integrating the Dogtag database with other systems such as IPA.
5. A new package pki-deploy contains the initial framework for a Python-based
installer/de-installer (pkispawn/pkidestroy) that will be used to install and configure a
Dogtag instance. This will ultimately replace the pki-setup installer/de-installer
(pkicreate, pkidestroy) package, and the pki-silent instance configuration (pkisilent) package.
6. Much of the focus of this release was on cleaning up and modernizing the Dogtag source code.
* Dogtag source code has been moved to git.
* Java coding standards have been revised – and the code has been reformatted to match those
standards.
* Initially, Eclipse reported about 13000 warnings in the dogtag code. Those have been reduced
to close to 2400. This included removing dead and unused code, replacing calls to deprecated
functions and replacing raw collections with type-safe generics.
NOTE: These numbers currently exclude console code.
* OSUtil is a package that has certain utilities that were not available when the Dogtag code
was originally written. These utilities are now available in current standard
libraries – and so this package has been eliminated entirely.
* Improved handling of short and long lived threads which allow threads to exit gracefully on
shutdown.

The builds can be found at the following links:

* http://pki.fedoraproject.org/pki/download/pki/10.0.0.alpha/fc16/RPMS/i686 – Fedora 16 (32-bit i686)
* http://pki.fedoraproject.org/pki/download/pki/10.0.0.alpha/fc16/RPMS/x86_64 – Fedora 16 (64-bit x86_64)
* http://pki.fedoraproject.org/pki/download/pki/10.0.0.alpha/fc16/SRPMS – Fedora 16 (Source)
* http://pki.fedoraproject.org/pki/download/pki/10.0.0.alpha/fc17/RPMS/i686 – Fedora 17 (32-bit i686)
* http://pki.fedoraproject.org/pki/download/pki/10.0.0.alpha/fc17/RPMS/x86_64 – Fedora 17 (64-bit x86_64)
* http://pki.fedoraproject.org/pki/download/pki/10.0.0.alpha/fc17/SRPMS – Fedora 17 (Source)

Dan Walsh: Secure Boot versus Ksplice.

2012-03-15T12:50:56+00:00

I have been attending many talks on Secure Boot. The basic idea behind secure boot is to ensure that the bios/bootloader and kernel have not been hacked. My understanding of how this is done is everything is signed and verified during the bootup. Nothing can run in the kernel that was not signed and verified.

Then we Oracle pushing Ksplice.

I can't help but ask the question?

Is ksplice a security disaster waiting to happen?

Adam Young: HATEOAS Openstack Keystone

2012-03-15T01:47:23+00:00

Of all the principals of REST, perhaps the most overlooked it Hypermedia as the Engine of Application State, or HATEOAS. This term tries to encapsulate several concepts together, but the primary is the principal of discoverability.

All future actions the client may take are discovered within resource representations returned from the server.

What does this mean for Keystone?

Keystone is currently a fairly simplistic application. It can issue tokens to users, and it can verify that a given token has been assigned to a user. Assuming for the moment that this is all we want to be able to do, we should be able to discover this from the top down.

Keystone listens on two ports: 5000 and 35357. Pointing a browser at either of these should be the start of the discovery process. Indeed, we see that the server returns three hyperlinks to us. The second and third links are for documentation, and lead us not to other resources controlled by the server, but back to docs.openstack.org. Only the first provides guidance, but it makes an interesting design decision. It points us to the sub url for a version of the Keystone library. On my development server, this url is http://localhost:5000/v2.0/. Submitting this URL only provides us with the same information again.

What should it show us? Lets forget for a moment that this service is specifically for programmatic use, and imagine instead that we are building a web based user interface. From previous experience, we know that the URL to request a token is http://0.0.0.0:5000/v2.0/tokens. However, this is specifically accessed via a POST action.

Lets ignore authentication for a moment. Keystone integrates authentication with token access. However, they are distinct options. If we remove the password value from the “request token” form we get something that accepts:

userid: The user that should be associated with the token. This can be the authenticated user, but there are use cases where it we might want to delegate the ability to create a token.
tenantId: This limits the scope of the token

So without authentication, other applications need a way to indicate that they should provide this data in order to create a token. For a webUI, this would be something like:

Aside from this being a functional form in its own right, it provides sufficient information to another system to indicate how to create a new token.

The URL of the token validation is of the form http://0.0.0.0:35357/v2.0/tokens/$TOKEN, we would want a form that allows the user to submit that value. A Form can do a Get action, but it cannot rewrite the target hyperlink without Javascript, something we would avoid here. We do not want to enumerate all tokens, as that would wrongly expose shared secrets. Thus, a post to an URL with a parameter of the token ID, as well as any other identifying information required would be more useful. This would be token id, user id, and tenant id. The HTML response code would be 200, and the body of the response would indicate valid or invalid. This post could also return a hyperlink to the original URL of the form http://0.0.0.0:35357/v2.0/tokens/$TOKEN, and that URL would still be accessible via HTTP GET.

This form could easily be displayed in JSON:

{"fields":["name","userid","tenantid"]}

This would could be extended with more information about fields types and so forth.

So from the tope level of the Keystone site, once the user is authenticated and has passed down through the hyperlinks:


Tenants
Tokens

And clicking through to tokens:


abcd
fghi

Add New Token





Validate Token

These last two forms probably should only be shown if the content type is set to HTM or XHTML.

Right now, even if content type is set to HTML, Keystone resorts to XML. The first step is to add a marshaller for HTML alongside to the JSON and XML marshallers, and then to support each of the content types equally.

Should Keystone support HATEOAS? I’d say yes. It makes the system more transparent and less surprising. It will give the implementors a means to debug at the server level, while not denying them the ability to hit things programmatically or from the CLI. It will also, I think make the desig more solid move forward, as it will be more visually obvious how the different members of the Keystone domain model fit together.

Adam Young: Dependency Injection in Python

2012-03-14T15:48:39+00:00

Object oriented design principals are not language specific. While there is variation from language to language on details of implementations, and some techniques are not appropariate to all languages, for the most part, good design is good design.

One principal worth emphasizing in any Object Oriented system is the Single Responsibility Principal. An object should do one thing, and do it well. However, that object will often need another object to complete a portion of its work. In simple cases, one object can control the lifespan of the dependency. As systems get more complex, these relationships grow more complex. In order to make objects reusable throughout a system and possibly even in other systems, the developer refactors the code, not chaning the behavior, but only the structure. One step is to Introduce a parameter to the constructor, in order to extract the construction code from the dependant object. What code now links up this dependency?

One reason that the Singleton Design Pattern is commonly used is that it provides an unmistakble instance of the object to use. Ideally, a Dependency Injection framework would provide the same degree of confidence, but with a more flexible means of providing mechanism for specifying how to create the dependent object. Using a singleton to get an object usually looks like this:

myobject=packagename.Instance

Which, of course, assumes that the instace has already been created. If you can’t be assured of that fact, the code is more likely to look like:

myobject=packagename.Instance()

Where instance is logic along the lines of:

instance=None
def Instance():
     if not instance:
         instance = MyLocalInstanceCreator()
     return instance

As you see here, I’ve split up the construction of the function from the caching of the resultant variable. Remember this technique…

In the Keystone code, we have a business object that encpsulates the Identity operations of the system: managing users, tenants, and roles. There are several implementations of this business object, depending on where the data is stores. We have one instace for SQL, and another for LDAP, as well as several others. To indicate that a given installation uses the SQL back end, the administrator should add the following line into the configuration file:

[identity]
driver = keystone.identity.backends.sql.Identity

The configuration for this Driver is then pulled from the appropriate section. For SQL, the block would look something like this:

[sql]
connection = sqlite:///bla.db
idle_timeout = 200
min_pool_size = 5
max_pool_size = 10
pool_timeout = 200

Whereas, if the Driver is set to the LDAP driver you would have text like this:

[ldap]
url = ldap://localhost
user = dc=Manager,dc=example,dc=com
password = freeipa4all
suffix = cn=example,cn=com

[identity]
driver = keystone.identity.backends.ldap.Identity

The class that implements the identity is now accessble from the configuration object via the api:

identity = CONF.identity.driver

And the SQL identity Driver loads itself. However, if random code in the application wants to access the identity driver, it now has to go looking for the singleton instance that has already constructed the identity object and called on that. SQL dervices from code in Common, as does the LDAP code, but the construction mechanisms are very different.

We can take these two branches and unify them into a single approach with the example above.

For SQL, we first define a function that creates the SQL Identity provider. To keep things simple for now, we will continue to use the constructor. We do the same for LDAP. To determine which to call looks like this:

identity=None
def Identity(CONF):
     if not identity:
         identity = get_class(CONF.idenity.driver)()
     return identity

I’m assuming get_class is something along the lines described here.

We are going to be seeing this pattern over and over again. For example, the identity driver needs the SQL database connection, but other business objects will also need the SQL database connection. The same goes for every external resource in the application. With a minor extension to our code, we can create a pattern of object access that is consistant across all global objects.

When we start up the application, we register the factory functions that create the instances based on the unique key used to look them up. In this case, we will use the same key were using before: the python class name.

def create_identity_driver():
     return get_class(CONF.idenity.driver)()

def factories = {keystone.identity.Driver: create_identity_driver}

instances = dict()

def get_instance(classname):
    try:
        instance = instances(classname)
    except:
        instance = factories[classname]()
        instances[classname] = instance
    return instance

This is the simplest case of inversion of control. Instad of creating objects directly, you register their factories, and let the application create them for you on demand. I’ve taken this a little further.

Please check out my full code, to include test cases, on github. This project will continue to evolve.

Dan Walsh: Fedora 17 New Security Feature part VIII - New SELinux Domains in F17

2012-03-13T14:47:35+00:00

Each Fedora we release a bunch of new domains that will run in permissive mode for the release. When the next release is released, the permissive domains are made enforcing.

In my blog,10 things you probably did not know about SELinux.. #4, I describe how you can interact with permissive domains.

Any ways these are the permissive domains in Fedora 16 that will now be confined.

Fedora 16 Permissive Domains

pptp_t quota_nld_t sshd_sandbox_t nova_ajax_t nova_api_t nova_compute_t nova_direct_t nova_network_t nova_objectstore_t nova_scheduler_t nova_vncproxy_t nova_volume_t rabbitmq_epmd_t rabbitmq_beam_t deltacloudd_t iwhd_t mongod_t thin_t chrome_sandbox_nacl_t matahari_sysconfigd_t

Fedora 17 Permissive Domains

couchdb_t (/usr/bin/couchdb)
blueman_t (/usr/libexec/blueman-mechanism)
httpd_zoneminder_script_t (/usr/libexec/zoneminder/cgi-bin(/.*)?)
zoneminder_t (/usr/bin/zmpkg.pl)
selinux_munin_plugin_t (/usr/share/munin/plugins/selinux_avcstat)
sge_shepherd_t (/usr/bin/sge_shepherd)
sge_execd_t (/usr/bin/sge_execd)
sge_job_t
matahari_rpcd_t (/usr/bin/sge_execd)
keystone_t (/usr/bin/keystone-all)
pacemaker_t (/usr/sbin/pacemakerd)

Of course I reserve the right to add to this list. our goal is to make sure all init/dbus services run with a type other then initrc_t.

If you see a process on your machine that is shipped from Fedora running as initrc_t, please open a bugzilla on SELinux policy.

Dan Walsh: Fedora 17 New Security Feature part VII - thumbnail protection.

2012-03-12T15:55:56+00:00

John Leyden wrote an interesting article Linux vulnerable to Windows-style autorun exploits, about how security researches had discovered that Linux is potentially vulnerable to a user sticking a USB device or CDRom into a locked machine. The basic idea was that "Nautilus" would execute thumbnail drive code, to display thumbnails icons in the file browsers based on the content on the removable media, even if the machine was locked. If the thumbnail executables were vulnerabile, a cracker could use the code used to process the thumbnail images to kill the screensaver/lock.

Never mind this, just plugging in a USB stick when you a logged in, could allow a cracker to take over your machine.

At that time, I wrote policy for all thumbnail drivers to be locked down with SELinux, but I only turned it on for confined users.
I and other users have been running this confinement thoughout Fedora 16.

In Fedora 17 I have turned this on for the unconfined user.

We are confining the following applications.

/usr/bin/evince-thumbnailer
/usr/bin/ffmpegthumbnailer
/usr/bin/gnome-exe-thumbnailer.sh
/usr/bin/gnome-nds-thumbnailer
/usr/bin/gnome-xcf-thumbnailer
/usr/bin/gsf-office-thumbnailer
/usr/bin/raw-thumbnailer
/usr/bin/shotwell-video-thumbnailer
/usr/bin/totem-video-thumbnailer
/usr/bin/whaaw-thumbnailer
/usr/lib(64)?/tumbler-1/tumblerd

I have seen these applications try to "execstack" when running mplayer executable on an thumbnails, kind of scary.

If you know of other thumbnail applications that get launched as thumbnails, please tell me.

Miroslav Grepl: How to confine a new service using an available policy

2012-03-08T21:56:41+00:00

Sometimes new services, which are a part of a project, are added. For example we could talk about cluster, cloudform, MRG services and so on. Yesterday I got a new bug with the following description

“matahari-qmf-rpcd runs as initrc_t”

It means that our policy does not cover the matahari-qmf-rpcd service which probably has been shipped recently. I know nothing about this service and I want to confine it. I am not sure if we have a policy for Matahari project so I use the selinux-policy-doc package to check it.

$ rpm -q selinux-policy-doc
selinux-policy-doc-3.10.0-96.fc17.noarch

The package is installed and I am able to find whether a policy exists

$ grep -r matahari /usr/share/selinux/devel/include/ |wc -l
256

There is a policy which I could use. We are interested in the /usr/share/selinux/devel/include/services/matahari.if policy file and the matahari_domain_template() interface. A template interface is a special interface to create a basic set of rules for services – template interfaces generate domain, executable and file types for a service.

In our case I declare the following local policy.

$ cat mymatahari.te
policy_module(mymatahari,1.0)

matahari_domain_template(rpcd)

Then I load and install it.

$ make -f /usr/share/selinux/devel/Makefile mymatahari.pp
$ semodule -i mymatahari.pp

You can see what types were added.

$ seinfo -t |grep matahari_rpc
matahari_rpcd_unit_file_t
matahari_rpcd_exec_t
matahari_rpcd_t

These three types were created by the matahari_domain_template() interface and we use them for an initial confinement. Now we need to tell SELinux that the matahari-qmf-rpcd service started by systemd should end up in the matahari_rpcd_t domain.

$ chcon -t matahari_rpcd_exec_t `which matahari-qmf-rpcd`
$ systemctl restart matahari-rpc.service
$ ps -eZ |grep matahari
system_u:system_r:matahari_rpcd_t:s0 3338 ? 00:00:00 matahari-qmf-rp

You are done and you have this new service running in the proper domain. Now you can use ausearch/audit2allow tools to check AVC messages

$ ausearch -m avc -ts recent |audit2allow
#============= matahari_rpcd_t ==============
allow matahari_rpcd_t bin_t:file getattr;
allow matahari_rpcd_t passwd_file_t:file { read getattr open };
allow matahari_rpcd_t usr_t:file { read getattr open };

The next step would be either file a new bug with these AVC messages and with the local policy or use the audit2allow tool to generate rules for the mymatahari.te policy file.

$ ausearch -m avc -ts recent |audit2allow -R |grep \(matahari >> mymatahari.te
$ make -f /usr/share/selinux/devel/Makefile mymatahari.pp
$ semodule -i mymatahari.pp

Dan Walsh: Fedora 17 New Security Feature part VI - man pages for SELinux user/role domains

2012-03-08T16:46:18+00:00

Ok, maybe this should be Security Feature IV.5 but Roman numerals do not support decimal points. :^)

After I wrote the tool to generate service domains man pages, Miroslav Grepl thought it would be a good idea to generate similar policy for user domains and roles.

We hacked up a new script called segenuserman, which generates 13 new SELinux user and Role man pages.

auditadm_selinux.8 git_shell_selinux.8 logadm_selinux.8 secadm_selinux.8 sysadm_selinux.8 user_selinux.8 xguest_selinux.8 dbadm_selinux.8 guest_selinux.8 nx_server_selinux.8 staff_selinux.8 unconfined_selinux.8 webadm_selinux.8

Note segenuserman also requires senetwork.py.

Here is the staff_selinux.8 for an SELinux user, and webadm_selinux.8 for an SELinux role.

I have also updated the SELinux service domain man pages to include booleans,process types, file context paths, better descriptions, network ports.

Here is an update zebra_selinux.8

Dan Walsh: Excuse me son, but your code is leaking !!!

2012-03-08T04:34:27+00:00

I have written over the years about leaked file descriptors, and what a pain they have been to SELinux.

C on Unix many many years ago was designed to leak by default. A file descriptor is leaked if you open a file descriptor or socket and then do a fork/exec. The new process will automatically get access to the file descriptor unless SELinux blocks it.

When SELinux blocks the leaked file descriptor you usually end up with a strange looking AVC about the new domain trying to read or write a random file or a socket owned by the parent or even worse an ancestor.

Talking with Uli Drepper the other day about leaked file descriptors. He reminded me that the gcc/glibc teams had added a flags to open,fopen, socket, accept4 to change the default.

man open
...
By default, the new file descriptor is set to remain open across an execve(2) (i.e., the FD_CLOEXEC file descriptor flag described in fcntl(2) is initially disabled; the O_CLOEXEC flag, described below, can be used to change this default).
...
O_CLOEXEC (Since Linux 2.6.23) Enable the close-on-exec flag for the new file descriptor. Specifying this flag permits a program to avoid additional fcntl(2) F_SETFD operations to set the FD_CLOEXEC flag. Additionally, use of this flag is essential in some multithreaded programs since using a separate fcntl(2) F_SETFD operation to set the FD_CLOEXEC flag does not suffice to avoid race conditions where one thread opens a file descriptor at the same time as another thread does a fork(2) plus execve(2).

Sadly this can not be made the default, but as a good programing practice all open/socket,accept and fopen calls should use this flag in order to close the file descriptor by default.

open(path, O_CLOEXEC | flags)
socket(DOMAIN, SOCK_CLOEXEC | type, PROTOCOL)
accept4(int sockfd, struct sockaddr *addr, socklen_t *addrlen, SOCK_CLOEXEC | flags);
fopen(path, "re")

If you can not open a file descriptor with one of these commands then you can execute

fctnl(fd, F_SETFD, FD_CLOEXEC)

He gcc developers or code analysys tools, you probably should catch when leaks happen, especially if they are not STDIN, STDOUT, STDERR.

Just be neat and stop leaking all over the place.

Dan Walsh: bash completion for setsebool/getsebool added for Fedora 17

2012-03-06T16:43:32+00:00

policycoreutils-python-2.1.10-26.fc17.x86_64 now has bash completion scripts for semanage and setsebool/getsebool

/etc/bash_completion.d/semanage-bash-completion.sh
/etc/bash_completion.d/setsebool-bash-completion.sh

# getsebool -<tab>
# getsebool -a

# getsebool samba_<tab>
samba_create_home_dirs   samba_export_all_ro      samba_share_fusefs
samba_domain_controller samba_export_all_rw      samba_share_nfs
samba_enable_home_dirs   samba_run_unconfined

# setsebool -<tab>
# setsebool -P<tab>

# setsebool -P samba_<tab>
samba_create_home_dirs   samba_export_all_ro      samba_share_fusefs
samba_domain_controller samba_export_all_rw      samba_share_nfs
samba_enable_home_dirs   samba_run_unconfined

semanage completion is a little more complicated.

# semanage <tab>
boolean     fcontext    login       node        port
dontaudit   interface   module      permissive user

# semanage fcontext -<tab>
-a           -d           --deleteall -f           --help       --modify
--add        -D           -e           --ftype      --locallist -t
-C           --delete     --equal      -h           -m           --type

# semanage fcontext -a -t samba<tab>
samba_etc_t                     samba_secrets_t
sambagui_exec_t                 samba_share_t
samba_initrc_exec_t             samba_unconfined_script_exec_t
samba_log_t                     samba_unit_file_t
samba_net_exec_t

...

Try it out. If you find problems, patches accepted... :^)

Adam Young: F17 Openstack Test Day on Thursday.

2012-03-06T01:38:57+00:00

If you want Openstack support for Fedora or RHEL, this day is for you! Once we get the F17 code stable, we will use that as the code base for EPEL, so lend a hand.

https://fedoraproject.org/wiki/Test_Day:2012-03-08_OpenStack_Test_Day

I’ll be lurking around to help out with Keystone questions, but at the same time I’ll also be involved with a local installfest so I expect to be logged in to IRC, but also very much walking around and answering questions….as well as running through test cases myself.

So join us:

IRC #fedora-test-day on Freenode
WebIRC: http://webchat.freenode.net/?channels=fedora-test-day

Dan Walsh: senetwork: new tool for examining SELinux networking policy.

2012-03-02T21:35:09+00:00

A couple of years ago I added some python bindings for setools. I hoped we would start to see new tools arise to analyze SELinux policy. Maybe making SELinux easier to user and understand.

Lately I have gone back to these tools and started playing with them to see what tools I could build.

Last couple of days I have hacked together a little script called senetwork.

The goal was to answering questions like:

What ports can a particular domain connect to? Bind to?

# senetwork ftpd_t
ftpd_t tcp name_connect
    ephemeral_port_t: 32768-61000
    ldap_port_t: 389,636,3268
    dns_port_t: 53
    ocsp_port_t: 9080
    kerberos_port_t: 88,750,4444
ftpd_t tcp name_bind
    ephemeral_port_t: 32768-61000
    ftp_port_t: 21,990
    ftp_data_port_t: 20
    unreserved_port_t: 1024-32767,61001-65535
    port_t: all ports with out defined types

What type(s) are associated with a particular port number?

# senetwork 8080
8080: tcp unreserved_port_t 1024-32767
8080: udp unreserved_port_t 1024-32767
8080: tcp http_cache_port_t 8080

What ports are associated with a particular port_type?

# senetwork ftp_port_t
ftp_port_t: tcp: 21,990
ftp_port_t: udp: 990

Basically senetwork looks at the argument and figures out whether or not it is a number, port type or domain type
and then prints out the information.

I plan on packaging up these little scriptlets with setools-console.

Adam Young: Booting a LiveCD as a Virtual Machine

2012-03-02T18:10:40+00:00

As a Fedora Community Member, I always feel guilty if I postpone trying out a testing release of Fedora. Since I have a limited amount of hardware, I can’t just install on a physical machine. Turns out that testing on a virtual machine is about as easy as it can be.

The following works well on Fedora 16 running KVM.

Download the LiveCD.

Open Up virt-manager

type in password and connect to your local hypervisor

Rightclick on localhost. From the popup menu select New
Add a new virtual machine, and select Import Existing Disk Image. Give the VM a name and click Forward.

Find the virtual machine. If you downloaded it to the default location, you’ll have to select Browse, and then Browse Local.

Mine is at /home/ayoung/Downloads/Fedora-17-Alpha-x86_64-Live-Desktop.iso

You can click through to the end of the wizard now if you want. The select boxes for OS Type and Version will have no real effect. Take the default for memory and CPUs, or increase them if you really want. Click finish and your VM should be booting shortly.

Now you really have no reason not to try out Fedora 17.

Adam Young: PKI for Keystone

2012-03-02T02:37:26+00:00

A recent discussion on the Openstack mailing list brought to light the high load that the Keystone server has due to each server having to authenticate each and every request against Keystone.

While appropriate caching will obviously limit some aspect of the traffic, there is another approach that will remove it altogether. If each token issued by the Keystone server is a document that is cryptographically signed by a private key, its authenticity can be verified by a public key published by the Keystone server. This transfers the burden from Network traffic to CPU for decrypting.

The public keys should have a relatively short lifespan, probably being updated no less frequently than once a day, the current lifespan of a ticket.

The public key should be published as an X509 certificate, signed by a local Certificate Authority.

Keystone should be able to publish a revocation list in case a user loses privileges. Since the lifespan of tokens is short, the revocation lists should be minimal, and do not need to be kept past the lifespan of the associated tokens.

Both Kerberos and Dogtag PKI have all of the capabilities listed above.

Adam Young: Keystone should move to Apache HTTPD

2012-03-01T17:34:36+00:00

Keystone and the other Openstack components run in an Eventlet based HTTP server. Eventlet and Greenlet (the project Eventlet is built on) are designed to be highly performant in networked environments due to their non-blocking nature. Everything is handled in a single thread, and scheduling is performed in user space. The one caveat is that not only must the code you write never block, the code you call must not block, either. If you are going to make a call into a third party library that performs I/O, you need to wrap that library in a thread pool.

For Keystone, every call is going to be going through to a Database layer, either SQL or LDAP. Which is in turn going to call into the native driver for that Database, or the LDAP libraries. Either way, it is a native call, and it has to be wrapped in a thread pool.

Keystone is an authentication hub. As such, it is literally the “Keystone” of the security architecture around Openstack. In order to do anything on any of the other services in Openstack, a use needs a token from Keystone. But in order to authenticate against Keystone, the user needs to provide a clear-text password. This approach may be sufficient to start development, but it is not going to be acceptable when a company needs to prove compliance with Sarbanes-Oxley. Or HIPPAA. For these cases, we want stronger encryption and better authentication management. The Eventlet based web server does not currently support forms of authentication other than Basic-Auth. Ideally, organizations would be able to employ their Kerberos or Public Key Infrastructure (PKI) assets to support their Openstack based authentication.

IPv6 is coming. The last block of IPv4 addresses has been allocated. For Cloud based deployments, people are going to need large numbers of routable IP Addresses. However, Eventlet does not currently support IPv6. Work is happening upstream, but it has not yet been commited, and will not be available for the Essex release of Openstack.

There is a simple solution. Keystone is a WSGI application, and has minimal dependencies on Eventlet. Deploying Keystone in an Apache HTTPD server with mod_wsgi running in prefork mode provides the same operating environment as Eventlet does. As the de facto standard open source web server, it has received a higher degree of scrutiny than most other software products. HTTPD support for GSSAPI/Kerberos authentication, Client and Server based certificates, and IPv6. It is well supported in all the major Linux distributions.

What would the drawbacks be? Probably the first thing people would look to from Eventlet is performance. I don’t have the hard numbers to compare Eventlet to Apache HTTPD, but I do know that Apache is used in enough high volume sites that I would not be overly concerned. The traffic in an Openstack deployment to a Keystone server is going to be about two orders of magnitude less than any other traffic, and is highly unlikely to be the bottleneck. Second is the fact that we would be pulling in dependencies to Apache HTTPD, and that configuring it would be different and more difficult than Eventlet. However, this is a fairly well trodden path. The benefits of putting all HTTP traffic behind ports 80 and 443 overwhelm the drawbacks of configuration.

Since Keystone has just gone through a major reworking, I realize that people might be reluctant to support a move like this. However, the effect on other components should be minimal or none. Apache HTTPD can be set up using the same ports that Keystone already uses, and thus replace an existing Keystone install with no changes to the configuration or code to the other services. The changes should be limited to Keystone alone.

The problem that Eventlet solves does not map to Keystone. The amount of work it would take to add the features Keystone really requires to Eventlet is significant, is difficult, and is likely to be far buggier than using well established and audited libraries. The simpler path forward is for Keystone to move over to Apache HTTPD. It is also the path for greater stability, security, and growth.

Dan Walsh: VMWare wants you to turn SELinux off? Really?

2012-03-01T13:50:07+00:00

i·ro·ny
1. The use of words to convey a meaning that is the opposite of its literal meaning: the irony of her reply, “How nice!” when I said I had to work all weekend.
2. an outcome of events contrary to what was, or might have been, expected.

One of the great features of KVM Virtualization is that each virtual machine is wrapped in an SELinux sandbox. All the software used to run a virtual machine on a host is called a hypervisor. When you run virtual machines, you have to worry about hypervisor vulnerabilities, which would allow your guest operating system to attack the host or other virtual machines you have running on the host.

We strive to make the Linux KVM Hypervisor as secure as possible, but bugs happen. SELinux can control what the virtual machine process can and can not do on the host machine. If you are running virtual machines on you Fedora or Red Hat box, you really should be running SELinux in enforcing mode.

It has come to my attention that VMWare support is suggesting people turn off SELinux... I guess SELiux is too complicated for the VMWare crack support team to handle.

At Red Hat we consider security a priority, VMWare I am not so sure.

If you are having a problem running any VMWare product on a RHEL or Fedora Operating system, contact me dwalsh@redhat.com and I will help you run your virtual machines and leave the security in place...

April 2011 "How it Works" issue of Popular Science, by Marie Pacella

Adam Young: FreeIPA Keystone LDAP Store

2012-03-01T03:25:06+00:00

The next interim release of Openstack Keystone will once again have LDAP support. I am developing against OpenLDAP to start, as that is what the LDAP support has been based on in the past. However, the directory server that backs FreeIPA works perfectly well, and provides a backend that allows for Keystone support.

I am running FreeIPA in a virtual machine (KVM) that runs on my laptop. I have a /etc/host entry that allows it to resolve. I’ve taken the pattern of using my laptops name as the domain for IPA to control. Since my laptop

ayoung@ayoung etc]$ hostname
ayoung.boston.devel.redhat.com

I’ve named the vm: f16server.ayoung.boston.devel.redhat.com. To install FreeIPA, I ran:

 ipa-server-install --forwarder=192.168.122.1  --setup-dns -n `hostname -d` -U -r `hostname  | tr "[:lower:]" "[:upper:]"` -p freeipa4all -a freeipa4all

Which should almost work for you, too: You will want to modify the forwarder to be one of the current nameserver values in /etc/resolv.conf

I loaded it up with sample data, including the following line as part of a batch command:

 {"method":"user_add", "params":[["zmarsh"],{"givenname":"Zackary","sn":"Marsh"}]},

Note that I first run

ipapasswd zmarsh

And set the password to 1 to one, and then I

kinit  zmarsh

to change the password to be the old standby of freeipa4all.

I made the following changes to my keystone.conf file:

diff --git a/etc/keystone.conf b/etc/keystone.conf
index 9020ea6..c929b42 100644
--- a/etc/keystone.conf
+++ b/etc/keystone.conf
@@ -23,17 +23,21 @@ max_pool_size = 10
 pool_timeout = 200

 [ldap]
-#url = ldap://localhost
-#tree_dn = dc=example,dc=com
-#user_tree_dn = ou=Users,dc=example,dc=com
-#role_tree_dn = ou=Roles,dc=example,dc=com
-#tenant_tree_dn = ou=Groups,dc=example,dc=com
-#user = dc=Manager,dc=example,dc=com
-#password = freeipa4all
-#suffix = cn=example,cn=com
+url = ldap://f16server.ayoung.boston.devel.redhat.com
+tree_dn = cn=accounts,dc=f16server,dc=ayoung,dc=boston,dc=devel,dc=redhat,dc=com
+
+user_id_attribute=uid
+user_tree_dn = cn=users,cn=accounts,dc=f16server,dc=ayoung,dc=boston,dc=devel,dc=redhat,dc=com
+role_tree_dn = cn=groups,cn=accounts,dc=f16server,dc=ayoung,dc=boston,dc=devel,dc=redhat,dc=com
+tenant_tree_dn = cn=groups,cn=accounts,dc=f16server,dc=ayoung,dc=boston,dc=devel,dc=redhat,dc=com
+user = uid=admin,cn=users,cn=accounts,dc=f16server,dc=ayoung,dc=boston,dc=devel,dc=redhat,dc=com
+password = freeipa4all
+ldapsearch -x -W -D  uid=admin,cn=users,cn=accounts,dc=f16server,dc=ayoung,dc=boston,dc=devel,dc=redhat,dc=com     -H ldap://f16server.ayoung.boston.devel.redhat.com  -b ""
+
+

 [identity]
-driver = keystone.identity.backends.kvs.Identity
+driver = keystone.identity.backends.ldap.Identity

 [catalog]
 driver = keystone.catalog.backends.templated.TemplatedCatalog

Yes, I am aware that using the LDAP protocol in the clear is not the preferred way to do things. LDAPS support is coming, I promise.

Now I fired up Keystone ( I run it in Eclipse, for integrated debugging) and first tested it using curl.

curl -s  -H "Content-Type:application/json"          -H "Accept:applicaton/json"  -d '{"auth":{"passwordCredentials":{"userId":"zmarsh", "password":"freeipa4all"} ,"tenantId":"ipausers"}}'   -X POST  http://0.0.0.0:35357/v2.0/tokens

Which returned the value.

{"access": {"token": {"expires": "2012-03-01T22:06:49Z", "id": "bfd6299ac37c4c91982867eb269b4505", "tenant": {"enabled": true, "id": "ipausers"}}, "serviceCatalog": [{"endpoints": [{"adminURL": "http://localhost:8774/v1.1/ipausers", "region": "RegionOne", "publicURL": "http://localhost:8774/v1.1/ipausers", "internalURL": "http://localhost:8774/v1.1/ipausers"}], "endpoints_links": [], "type": "compute", "name": "'Compute Service'"}, {"endpoints": [{"adminURL": "http://localhost:35357/v2.0", "region": "RegionOne", "publicURL": "http://localhost:5000/v2.0", "internalURL": "http://localhost:35357/v2.0"}], "endpoints_links": [], "type": "identity", "name": "'Identity Service'"}], "user": {"username": "Marsh", "roles_links": [], "id": "zmarsh", "roles": [], "name": "Marsh"}}}

And hit it from Keystone client (running in the python interpreter)

>>> from keystoneclient.v2_0 import client
>>> keystone = client.Client(username='Marsh', password='freeipa4all', tenant_name='', auth_url='http://0.0.0.0:5000/v2.0')
>>> print keystone

One trick that makes ipa a great teaching tool for ldap is running ipa show and ipa find commands with the –raw and –all switches. For example, to confirm the distinguished name of the test user, I can run:

[root@f16server ~]# ipa user-show zmarsh --all --raw
  dn: uid=zmarsh,cn=users,cn=accounts,dc=f16server,dc=ayoung,dc=boston,dc=devel,dc=redhat,dc=com
  uid: zmarsh
  givenname: Zackary
...

Some details and warts.

I’m using FreeIPA’s User Groupsfor the tenant grouping. I’d prefer long term to use netgroups.
Keystone Roles are not yet implemented.
The User object usese SN for the user name, which is not a unique field.

Dan Walsh: Fedora 17 New Security Feature part VI - systemd-journal

2012-02-29T14:53:13+00:00

There has been a lot written about the systemd-journal, this link gives a pretty good description of why it is good from a security point of view, although I don't see this as a full replacement of syslog.

http://techspear.com/2011/11/systemd-journal-an-alternate-for-the-syslog/

Since the syslog format is ubiquitous, I don't see it going away. Also systemd-journal caused a lot of people who were working on "Structured Logging" to get all up in arms over it, since Lennart and Kay did not work with them.

I still like it.

systemd has become the central point of launching system apps, so it knows more about what is going on in the system then any other process save the kernel.

Years ago when the audit system was being build Karl MacMillan of Tresys believed that some of the problems that the audit system was trying to fix could be handled by extending syslog to record all the information about the sending process. ALL of the UIDs associated with a process as well as recording the SELinux Context. Systemd-journald now does this.

Let me give an example of where systemd-journal could be used to increase security.

SELinux controls processes by only allowing them to do what they were designed to do. Sometimes even less depending on the security goals of the policy writer. This means SELinux would prevent a hacked ntpd process from doing anything other then handle Network Time. SELinux would prevent the hacked ntpd from reading mysql database or credit card data from the users home directory, even if the ntpd process was running as root. However, since the ntpd process sends syslog messages, SELinux would allow the hacked process to continue to send syslog messages. The hacked ntpd could format syslog messages to match other daemons and potentially trick and administrator or even better a tool that reads the syslog file (Intrusion detection tools?) into doing something bad. If all messages were verified with the systemd-journal then the administrator or syslog analysis tool could notice that ntpd_t is sending messages about sshd, and we could realize your ntpd daemon was hacked.

.cursor=s=f328cc4b2615417189ab76b00c7ae041;i=2;b=4c3d0faf6b774fb7930972c1a4a5f87
.realtime=1329940273078467
...skipping...
SYSLOG_IDENTIFIER=sshd
SYSLOG_PID=2302
MESSAGE=sshd Fake message from sshd.
_PID=2302
_UID=0
_GID=0
_COMM=ntpd
_EXE=/usr/sbin/ntpd
_CMDLINE=/usr/sbin/ntpd -n -u ntp:ntp -g
_SYSTEMD_CGROUP=/system/ntpd.service
_SYSTEMD_UNIT=ntpd.service
_SELINUX_CONTEXT=system_u:system_r:ntpd_t:s0
_SOURCE_REALTIME_TIMESTAMP=1330527027590337
_BOOT_ID=4c3d0faf6b774fb7930972c1a4a5f870
_MACHINE_ID=432d8198a8fc421caf2dca48ccde1cf2
_HOSTNAME=dhcp-189-250.bos.redhat.com

Dan Walsh: Fedora 17 New Security Feature part V - sudo can now use sssd for authorization data (sudoers)

2012-02-28T17:03:55+00:00

Currently sudo can be configure to read the /etc/sudoers file locally or to look it up via sudoers content via LDAP. The LDAP server provides a useful feature for organizations which wanted to centralize authorization data.

But, as in all types of centralized authorization/authentications systems, it does not work well when your machine is disconnected
from the network.

sssd - System Security Services Daemon to the rescue.

sssd was added to Fedora a few releases ago, as I blogged about back in March 2011.

One of the biggest benefits of sssd is that it allows for disconnected access to cached authorization/authentication data.
A new feature in Fedora 17 adds sssd as a source for sudoers data.

The benefits of this integration as described on the feature page are:

offline access - sudoers rules would be stored in a persistent cache, allowing sudo to fetch the rules seamlessly even in cases when the LDAP server is not reachable such as user roaming with a laptop.
unified configuration of LDAP parameters such as the servers used, timeout options and security properties at one places (sssd.conf)
sudo would take advantage of the advanced features SSSD has such as server fail over, server discovery using DNS SRV lookups and more
only one connection to the LDAP server open at a time resulting in less load on the LDAP server and better performance

And from an SELinux point of view one less network access for the sudoers application.

caching of the rules - less load on the LDAP server and better performance on the client side as the client wouldn't have to go to the server with each request
back end abstraction - data may be stored in NIS or other databases and accessed by the sudo transparently

Imagine if sssd and IPA could eventually cache SELinux Roles/Confined Users, maybe sometime in the not too distant future ...

Dan Walsh: Fedora 17 New Security Feature part IV - man pages for SELinux service domains

2012-02-27T16:11:34+00:00

A couple of weeks ago, I began to look at the man pages for SELinux policy that we had written for SELinux several years ago.    I wanted to update them and maybe add a few new ones.    When I looked at the httpd_selinux man page, I noticed it was missing lots of descriptions of booleans and file types associated with the httpd domain. When I started adding the boolean definitions, I quickly became board and realized this would not scale.

I decided to write a tool genman.py, that would query the SELinux Policy and write a man page for every executable service domain.
DOMAIN_selinux.8

I made a few assumptions that a service domain had an entrypoint ending in "_exec_t". Which we have pretty much standardized on. Then I truncated the first part of the name off and searched for types and booleans containing this name.

httpd_exec_t -> httpd for example.

I actually took is a step further and truncated a "d" off if the domain name ended in "d", since this is common.

httpd -> http.

Booleans have a description in policy so this was fairly easy to add to the man pages.

# semanage boolean -l | grep http

Would give you all the booleans that mention http, for example.

Since we don't have a description for each file type associated with a domain, I had to hard code a big it/then table with common definitions, for example.

def explain(f, k):
    if f.endswith("_var_run_t"):
        return "store the %s files under the /run directory." % prettyprint(f, "_var_run_t")

Then I added a special section for any domains that use public_content_t.

Bottom line the tool was generated over 400 man pages that have been added to the selinux-policy-doc rpm.

For example abrt man page.

Are these man pages perfect? NO.

But they are a lot better then nothing. Now if you want to know the types/and or booleans associated with a service, all you need to execute is man SERVICE_selinux.

If anyone wishes to enhance this, by perhaps adding file context definitions, patches welcomed...

Josh Bressers: How to use a cryptostick with Gnu Privacy Guard

2012-02-27T13:40:00+00:00

I've had an OpenPGP smartcard for quite some time now. I recently acquired a Crypto Stick as well thanks to rcvalle. Using these things with GnuPG isn't very clear and took a lot of work to figure out. Rather than let others struggle through all this, I'll document the procedure here.

The basic idea behind using a smartcard to hold your GPG keys is that an attacker can't steal the key. The worst they could do is to sign or decrypt something while you have the card inserted.

Please take the time to understand what's going on here. I have lots of examples to make this all work, but be sure you understand what's happening. Public key cryptography is hard, you should at least have a basic grasp of what's happening here. This howto should be treated as an example, not a cookie cutter recipe to follow.

This is a rather long post, more after the fold.

Continue reading "How to use a cryptostick with Gnu Privacy Guard"

Josh Bressers: Is Linus' Law real?

2012-02-26T13:55:00+00:00

Long long ago, Eris Raymond coined "Linus' Law".

given enough eyeballs, all bugs are shallow.

Last week Coverity released a report showing that open source software has a lower defect rate than proprietary software. This of course has some folks claiming that Linus' Law works!

http://techcrunch.com/2012/02/23/with-many-eyeballs-all-bugs-are-shallow/

Now I'm about as big of a fan of open source as they come, but I'm not sure if this is the proper course for cause and effect. I've done a lot of thinking about Linus' Law in the past few months as part of the Red Hat Product Security Team. What the Coverity report shows is that open source has fewer of the kind of defects Coverity can detect. That's really it.

On the topic of open source code quality and bugs though, I think there are a few more important things to consider.

1) The source code is available.

We've all written horrible horrible code when we know nobody will look at it. If I know someone will see my work, especially THE WHOLE WORLD, I'm going to spend a few extra minutes to make it look nice, which will help reduce bugs.

2) The original author is probably still around

One of the problems you can see with proprietary software is that the developers don't own the code. If a developer gets a new job, they'll probably never see it again. With open source, regardless of where you work, you're going to work on your projects. This "old knowledge" is a very powerful thing.

3) Anyone can help

If you report a bug to a proprietary vendor, they have to justify the fix from a business perspective. If the bug is obscure, or doesn't affect functionality, they may decide not to fix it. With open source, anyone can submit a patch. That means you can benefit from the long tail of contributions. The core 5% of people may write 95% of the software, but it's the other 95% of users and their 5% patches that can make the real difference. Those 5% patches are likely bugfixes, not new functionality.

4) The Distribution model is powerful

I worked for a company that write proprietary software once. The use and testing are very well defined. If a user found a bug because they were doing something weird, they were told to go away. With open source, there are hundreds of Distributions, all of them do things a little bit different. These corner cases improve overall code quality (a bug is a bug).

I suspect the overall message here isn't that Linus' Law works (it might, I'm not sure honestly). The message is that open source works. Why can't be pinned down to one thing, it's a lot of factors all coming together. Maybe all bugs ARE shallow with enough eyeballs. It's more likely though that the message should be "more eyeballs is better than less eyeballs".

What do you think?

Dan Walsh: Fedora 17 New Security Feature part III - systemd starting daemons

2012-02-24T17:02:20+00:00

Ok, this is not really a new feature in Fedora 17.

systemd has been starting some daemons in Fedora 16, but more and more daemons and privileged processes are being started by systemd in 17.

Why is this a security feature?

Symbols: @ means Execute, -> indicates transition, === indicates a client/server communication

In the past daemons would be started in two ways. At boot init (sysV) launches an initrc script and then this script would launch the daemon, or an admin could log in and launch the init script by hand causing the daemon to run.

From an SELinux point of view this looked like:

init_t @ initrc_exec_t -> initrc_t @ httpd_exec_t -> httpd_t:
This apache processes would end up running with the full label of:
system_u:system_r:httpd_t:s0
If apache created content it would be labeled
system_u:object_r:httpd_sys_content_rw_t:s0

When an administrator started restarted the process say through service httpd restart
unconfined_t @initrc_exec_t -> initrc_t @httpd_exec_t -> httpd_t
The process would adopt the user portion of the SELinux label that started it
unconfined_u:system_r:httpd_t:s0
Content would be created by this apache would be:
unconfined_u:object_r:httpd_sys_content_rw_t:s0
SELinux ends up confusing the user since we have to ignore the user componant of the SELinux label. If you wanted to write policy to confine based on user type, you can't.

With systemd this improves greatly.

The transitions is very different.
init_t @ httpd_exec_t -> httpd_t
system_u:system_r:httpd_t:s0

But if you want to restart the Apache daemon as admin you now do.
unconfined_t === init_t @ httpd_exec_t -> httpd_t
system_u:system_r:httpd_t:s0

With systemd we don't have the labeling problem and we can tighten up the SELinux policy.

Systemd starting daemons affects more than just SELinux.

Over the years lots of vulnerabilities and administration failures had to be worked around because of admins restarting daemons. Daemons need to be coded to cleanup any leaked information from the admin process influencing the way the Daemon ran.

Need to clean $ENV
Need to change working directory

cd / in order to make sure they don't blow up because they lack access to the current working directory (service script does for them).

Need do something with the terminal, close stdin, stdout, stderr after they start.

In SELinux we are always in a quandary about this, since if we allow the daemon access to the terminal, a hacked daemon could present the admin with passwd: and trick him into revealing the admin password.)

Changing the controlling terminal
Change the handling of signals
...

If a daemon writer screws up on one of these he could make the system vulnerable or end up with unexpected bugs.

Using systemd to start daemons, guarantees the daemon always gets started with the same environment whether they are started at boot or restarted by an administrator.

Dan Walsh: Fedora 17 New Security Feature part II - PrivateTmp

2012-02-23T14:34:28+00:00

One of the reasons I am really excited about Fedora 17 is amount of new Security Features we have added, and not all of them involve SELinux ...

As I blogged a few weeks ago, we have stopped the ability for one process to look at another processes memory even if they have same UID, with the deny_ptrace feature.

PrivateTmp

But today I want to talk about PrivateTmp. One of my goals over the years has been to stop system services from using /tmp.

I blogged about this back in 2007. Any time I have found out a daemon was using /tmp, I tried to convince the packager to move the content to /run directory if it was temporary or /var/lib if it was permanent.

Over the years there have been several vulnerabilities (CVEs) about this. For example:

CVE-2011-2722, which covered a case where hplib actually included code like.

fp = fopen ("/tmp/hpcupsfax.out", "w"); // <- VULN
system ("chmod 666 /tmp/hpcupsfax.out"); // <- "

Meaning if you setup a machine running cups daemon, a bad user or a application that a user ran could attack your system.

I have convinced a lot of packages to stop using /tmp, but I can't get them all and in some cases services like Apache,  need to use /tmp.   Apache runs lots of other packages that might store content in /tmp.

Well systemd has added lots of new security features (more on these later).  

PrivateTmp, which showed up in Fedora 16,  is an option in systemd unit configuration files.

      > man system.unit
       ...
       A unit configuration file encodes information about a service, a socket, a device, a mount point, an automount point, a   
     swap file or partition, a start-up target, a file system path or a timer controlled and supervised by systemd(1).

     > man systemd.exec
     NAME
       systemd.exec - systemd execution environment configuration
     SYNOPSIS
       systemd.service, systemd.socket, systemd.mount, systemd.swap
     DESCRIPTION
       Unit configuration files for services, sockets, mount points and swap devices share a subset of configuration 
       options which define the execution environment of spawned processes.
      ...
       PrivateTmp=
           Takes a boolean argument. If true sets up a new file system namespace for the executed processes and mounts a 
           private /tmp directory inside it, that is not shared by processes outside of the namespace. This is useful to secure 
           access to temporary files of the process, but makes sharing between processes via /tmp impossible. 
           Defaults to false.

PrivateTmp causes systemd to do the following any time it starts a service with this option turned on:

   Allocate a private "tmp" directory
   Create a new file system namespace 
   Bind mount this private "tmp" directory within the namespace over /tmp
   Start the service.  

This means that processes running with this flag would see a different and unique /tmp from the one users and other daemons sees or can access.

Note:  We have found bugs using PrivateTmp in Fedora 16, so make sure you test this well before turning it on in Production.

For Fedora 17, I opened a feature page that requested all daemons that were using systemd unit files and /tmp to turn this feature on by default.

Apache and Cups now have PrivateTmp turned on by default in Fedora 17, along will several other daemons.

Giving three options as a Developer of System Service, I still believe that you should not use /tmp, you should use /run or /var/lib.  But if you have to use /tmp and do not communicate with other users then use PrivateTmp.  If you need to communicate with users be careful...

Mark J Cox: Enterprise Linux 5.7 to 5.8 risk report

2012-02-21T14:52:00+00:00

Red Hat Enterprise Linux 5.8 was released today (February 2012), seven months since the release of 5.7 in July 2011. So let's use this opportunity to take a quick look back over the vulnerabilities and security updates made in that time, specifically for Red Hat Enterprise Linux 5 Server.

Red Hat Enterprise Linux 5 is coming up to its fifth year since release, and is supported for another five years, until 2017.

Errata count

The chart below illustrates the total number of security updates issued for Red Hat Enterprise Linux 5 Server if you had installed 5.7, up to and including the 5.8 release, broken down by severity. It's split into two columns, one for the packages you'd get if you did a default install, and the other if you installed every single package (which is unlikely as it would involve quite a bit of manual effort to select every one). For a given installation, the number of package updates and vulnerabilities that affected you will depend on exactly what packages you have installed or removed.

So, for a default install, from release of 5.7 up to and including 5.8, we shipped 42 advisories to address 118 vulnerabilities. 4 advisories were rated critical, 13 were important, and the remaining 25 were moderate and low.

Or, for all packages, from release of 5.7 up to and including 5.8, we shipped 71 advisories to address 177 vulnerabilities. 7 advisories were rated critical, 16 were important, and the remaining 48 were moderate and low.

Critical vulnerabilities

The 7 critical advisories addressed 20 critical vulnerabilities across 4 different packages:

An update to OpenJDK 6 Java Runtime Environment, (October 2011) where a web site hosting a malicious Java applet could potentially run arbitrary code as the user.

An update to the MIT krb5 telnet daemon (December 2011) where a remote attacker who can access the telnet port of a target machine could use this flaw to execute arbitrary code as root. Note that the krb5 telnet daemon is not installed or enabled by default, and the default firewall rules block remote access to the telnet port. This flaw did not affect the more commonly used telnet daemon distributed in the telnet-server package.

Updates to PHP and PHP 5.3 (February 2012) where a remote attacker could send a specially-crafted HTTP request to cause the PHP interpreter to crash or, possibly, execute arbitrary code. This flaw was caused by the fix for CVE-2011-4885.

Three updates to Firefox (August 2011, September 2011, November 2011) where a malicious web site could potentially run arbitrary code as the user running Firefox.

Updates to correct 19 out of the 20 critical vulnerabilities were available via Red Hat Network either the same day or the next calendar day after the issues were public. The update to krb5 took 2 calendar days because it was public on Christmas day.

Overall, for Red Hat Enterprise Linux 5 since release until 5.8, 98% of critical vulnerabilities have had an update available to address them available from the Red Hat Network either the same day or the next calendar day after the issue was public.

Other significant vulnerabilities

Although not in the definition of critical severity, also of interest during this period were a couple of remote denial of service flaws that were easily exploitable:

A flaw in BIND, CVE-2011-4313, fixed by RHSA-2011:1458 (bind) and RHSA-2011:1459 (bind97). A remote attacker could use this flaw to cause BIND to crash.

A flaw in Apache HTTP Server, CVE-2011-3192, fixed by RHSA-2011:1245. A remote attacker could use this flaw to cause httpd to use an excessive amount of memory and CPU time.

In addition, updates to Firefox, NSS, and Thunderbird were made to blacklist a compromised Certificate Authority.

Previous update releases

To compare these statistics with previous update releases we need to take into account that the time between each update release is different. So looking at a default installation and calculating the number of advisories per month gives the following chart:

This data is interesting to get a feel for the risk of running Enterprise Linux 5 Server, but isn't really useful for comparisons with other major versions, distributions, or operating systems -- for example, a default install of Red Hat Enterprise Linux 4AS did not include Firefox, but 5 Server does. You can use our public security measurement data and tools, and run your own custom metrics for any given Red Hat product, package set, timescales, and severity range of interest.

See also: 5.7, 5.6, 5.5, 5.4, 5.3, 5.2, and 5.1 risk reports.

Dan Walsh: How can I allow a process to listing all processes on a system.

2012-02-20T16:45:00+00:00

SELinux blocks lots of domains from listing all processes on the system.

Lots of useful information can be optained from reading the process info on a machine, so we would like to block this by default. But sometimes users/policy writers really need to allow their domains to be able to list the processes on a system.

Ole on the Fedora SELinux Users Mail list asked:

I have a problem with SELinux not allowing PHP to list other users' processes with the "ps" command.

If I disable SELinux with "setenforce 0" it works immediately.

Is it possible to allow PHP to do this without disabling SELinux completely?

Processes are listed by reading all of the contents of /proc. SELinux linux labels everything in /proc based on the label of the process.

ps -eZ | grep sshd | head -1
system_u:system_r:sshd_t:s0-s0:c0.c1023 853 ? 00:00:00 sshd

ls -lZ /proc/853 | head -1
dr-xr-xr-x. root root system_u:system_r:sshd_t:s0-s0:c0.c1023 attr

If you want a confined process to run ps, it needs to list /proc/PID, it needs to read certain files in this directory, needs to read symbolic links in this directory and needs to getattr on the process.   When writing policy we have added a macro for this access.

define(`ps_process_pattern',`
    allow $1 $2:dir list_dir_perms;
    allow $1 $2:file read_file_perms;
    allow $1 $2:lnk_file read_lnk_file_perms;
    allow $1 $2:process getattr;
')

If we wanted to allow one process type (myuser_t) to read another process /proc data on sshd (sshd_t), we would need to write a line like:

ps_process_pattern(myuser_t, sshd_t)

What if I want to allow a type to list all processes types?

In SELinux policy language we use attributes are used to group multiple types together.
SELinux calls processes "domains". When we write policy we always give process types the domain attribute.

So if you wanted to allow a process myuser_t to list all the processes on a system, you would write a rule like.

ps_process_pattern(myuser_t, domain)

Dominic Grift answered Ole question by suggesting he install a local policy module that looked like:

policy_module(mytest, 1.0.0)
gen_require(` 
  type httpd_t; 
  attribute domain; 
')
ps_process_pattern(httpd_t, domain)

This works great.  Note that the apache daemon runs all php scripts within its process space, to they run as httpd_t.

Another solution would be to use an interface that we have defined in policy to allow this, domain_read_all_domains_state.  

The /usr/share/selinux/devel/include/kernel/domain.if interface file defines several interfaces that can be used to interact with all domains.  An alternative policy module could have been written:

policy_module(mytest, 1.0.0)
gen_require(` 
  type httpd_t; 
')
domain_read_all_domains_state(httpd_t)

Adam Young: Working with Keystone Authenticate

2012-02-17T22:03:07+00:00

Here is a little utility I’ve worked up while working with the Openstack Keystone code.

To extract the token out of the JSON, use the following pyton script

#!/usr/bin/python

from sys import stdin
import json
print json.load(stdin)['access']['token']['id']

Which I save in ~/bin/extract_keystone_id.py

Here’s the Curl to fetch a token from Keystone, assuming you ‘ve loaded up the sample data from the unit tests:

curl -v   -H "Content-Type:application/json"  -s  -H "Accept:applicaton/json"  -d '{"auth":{"passwordCredentials":{"userId":"foo", "password":"foo2"} ,"tenantName":"bar"}}'   -X POST  http://0.0.0.0:35357/v2.0/tokens  | ~/bin/extract_keystone_id.py

Adam Young: Openstack Keystone LDAP Redux

2012-02-17T17:27:55+00:00

A recent change in the structure of the Openstack Keystone architecture resulted in the loss of support for an LDAP Backend. I’ve been working to rectify that. Here’s my set up and the design decisions I’ve made so far. Since this code is not yet submitted for code review, there is a good chance that it will change prior to deployment.

Users will be stored in a flat collection. ou=Users,$SUBTREE and be based on the standard LDAP objectClass inetOrgPerson which is defined in /etc/openldap/schema/inetorgperson.ldif. Currently, only two fields are used: cn and sn. cn is used for the bind call, and is the id field in the user object.

Tenants are in a collection that is a peer to Users. Tenants are instancs of the groupOfNames object class defined in /etc/openldap/schema/core.ldif. Tenant membership is indicated by the presence of the User’s DN in the tenant’s members attribute.

Roles are instances of the LDAP object class organizationalRole defined in /etc/openldap/schema/core.ldif. Role assignment is indicated by the presence of the User’s DN in the roleOccupant attribute.

Configuration of LDAP for the Keystone server is provided by the [LDAP] stanza in the appropriate keystone.conf file. Here are the supported values

url
user
password
suffix
use_dumb_member
user_tree_dn
tenant_tree_dn
role_tree_dn

And an example of what my config file looks like:

[ldap]
url = ldap://localhost
tree_dn = dc=younglogic,dc=com
user_tree_dn = ou=Users,dc=younglogic,dc=com
role_tree_dn = ou=Roles,dc=younglogic,dc=com
tenant_tree_dn = ou=Groups,dc=younglogic,dc=com
user = dc=Manager,dc=younglogic,dc=com
password = freeipa4all
backend_entities = ['Tenant', 'User', 'UserRoleAssociation', 'Role']
suffix =cn=younglogic,cn=com

[identity]
driver = keystone.identity.backends.ldap.Identity

Not all of these fields need to be specified. It is expected that the user will supply simply the suffix field, and not override the values of user_tree_dn,role_tree_dn, or tenant_tree_dn.

backend_entities is not currently honored. It is expected that LDAP will instead either manage all of these or non e of them, with token management handled by a different backend provider.

use_dumb_member is still honored from the previous incarnation, but has not been tested, nor do I understand the intention of this code.

The unit tests for the LDAP code use a common code sournce with the other Identity management backends. To run just the LDAP unit tests, from the Keystone directory, run

 python ./run_tests.py  test_backend_ldap

Additionally, the unit tests can be run against a live OpenLDAP server by running.

 python ./run_tests.py  _ldap_livetest

All tests pass successfully on my development machine as of this posting.

I’m running Fedora 16, which supports OpenLDAP. Specifically I am running openldap-servers-2.4.26-5.fc16.x86_64. To start the service, run

sudo service slapd start

To configure the server, I use a file I call manager.ldif:

dn:  olcDatabase={2}hdb,cn=config
changetype: modify
replace: olcSuffix
olcSuffix: dc=younglogic,dc=com
-
replace: olcRootDN
olcRootDN: dc=Manager,dc=younglogic,dc=com
-
add: olcRootPW
olcRootPW: {SSHA}lBDIdfwvZkITal0k9tdhiCUolxpf6anu

You should modify the suffix for your organization.
Execute the configuration with:

 sudo ldapmodify -Y EXTERNAL -H ldapi:///  -f ./manager.ldif

And test that you can now do a simple bind to the localhost server.

ldapsearch -x -D "dc=Manager,dc=younglogic,dc=com" -H ldap://localhost  -w freeipa4all  -b ou=Groups,dc=younglogic,dc=com "(objectClass=*)"

Now set up the subtree for Keystone. I use file I call org.ldif

dn: dc=younglogic,dc=com
dc: younglogic
objectClass: dcObject
objectClass: organizationalUnit
ou: younglogic

dn: ou=Groups,dc=younglogic,dc=com
objectClass: top
objectClass: organizationalUnit
ou: groups

dn: ou=Users,dc=younglogic,dc=com
objectClass: top
objectClass: organizationalUnit
ou: users

dn: ou=Roles,dc=younglogic,dc=com
objectClass: top
objectClass: organizationalUnit
ou: users

Technically, the Roles ou is not required. My original thought was that this collection would contain the superset of roles possible for all of the Tenants. However, I have not implemented that.

Current code is commited to Github I will update this link if I rebase the branch.

Update: fixed typos in the config file segment. user_tree_dn etc should start with ou, not cn.

Adam Young: Programmatic EXTERNAL SASL connection to OpenLDAP

2012-02-17T16:30:27+00:00

The documentation on the OpenLDAP site discusses modifying the ldif files used to start up the server. If you try to do this on a Fedora or Debian based install, you will find that the server does not start up. The HASH of the files is stored and compared with the contents at start up time. There is a better way.

On my OpenLDAP install, there are three databases served by SLAPD. The first two are for configuration and monitoring. The third is the one that acts as the backing store for authentication and other data that is publicly served. When the server starts up, it is configured with a common name of cn=example,cn=com, which is obviously sample data. To modify this, requires changing the values in the config database.

Below is an ldif file that would change the Common name, as well as set the userid and password for managing the directory

dn:  olcDatabase={2}hdb,cn=config
changetype: modify
replace: olcSuffix
olcSuffix: dc=younglogic,dc=com
-
replace: olcRootDN
olcRootDN: dc=Manager,dc=younglogic,dc=com
-
add: olcRootPW
olcRootPW: {SSHA}lBDIdfwvZkITal0k9tdhiCUolxpf6anu

I generated the HASH using the slappasswd command line tool.
To modify the config, you then execute ldapmodify.

sudo ldapmodify -Y EXTERNAL -H ldapi:///  -f /home/ayoung/etc/managerbase.ldif

What is this EXTERNAL? It is a SASL mechanism that uses the underlying system configured authentication. This is the NSS value that you would get back from getent. The default install protects the configuration database using the root credentials. The URL ldapi:/// is a Unix socket connection to /var/run/ldapi.

What happens if you want to modify the configuration pragmatically? The steps to make a SASL External connection are not to clear. In order to figure out how to do it, I’ve started poking inside of the ldapmodify code from the openldap source. The CLI tools are under openldap/clients/tools/. The connection is created in the file common.c. From what I’ve seen elsewhere on the web, I know it needs to resolve to one of the ldap*bind calls. In my file, inside the function tool_bind, I see it on line 1469

	rc = ldap_sasl_interactive_bind_s(
          ld, binddn, sasl_mech,
	   sctrlsp, NULL, sasl_flags, lutil_sasl_interact, defaults )

Now, I’ve run this through ltrace and I’ve seen

ldap_sasl_interactive_bind_s(0x1abf290, 0, 0x1abf030, 0, 0

So I know to expect binddn to be null, and sasl_mech needs to have a real value. Look in the argument parsing part of the code for the -Y flag tells that this is a pass through of the string passed on the command line.

    case 'Y':
        /*error chcking ellided here*/
	sasl_mech = ber_strdup( optarg );

So that should be the string EXTERNAL for our purposes.

The next two parameters are 0, sctrlsp and (surprise) NULL.

sasl_flags looks like it is set to the default in the top of the file and never modified in our code path:

unsigned	sasl_flags = LDAP_SASL_AUTOMATIC;

That leaves the last two parameters. One is a callback function lutil_sasl_interact and one is the defaults structure. The function lutil_sasl_interact is defined in the file openldap/libraries/liblutil/sasl.c. Between it and the function interaction which it calls, we are talking about 200 lines of code. For now, I am just going to cut and paste that code into my C file and get all of the headers coorect to run it. Later, I’ll step through it in the debugger to see what it is really doing.

The defaults structure is also defined in the sasl/c file specified above. From the ldap_bind man page:

The interact function uses the provided defaults to handle requests from the SASL library for particular authentication parameters. There is no defined format for the defaults information; it is up to the caller to use whatever format is appropriate for the supplied interact function. The sasl_interact parameter comes from the underlying SASL library. When used with Cyrus SASL this is an array of sasl_interact_t structures. The Cyrus SASL library will prompt for a variety of inputs, including:…

Again, I will cut and paste this code into my file and get it running. In order to compile I need to add the flags

CFLAGS=-lldap -llber -lsasl2 -g -I/usr/include/sasl

Once I can compile and run, I can dump out the contents of the config directory. Stepping through the code I discover a few things. In the code that builds the defaults, the non-zero values are. defaults->authcid = “root” and defaults->mech “EXTERNAL”. When the function lutil_sasl_interact is called, the parameters are: The ldap structure from our init, flags=0, defaults, and in, which is cast to at sasl_interact_t. The only part of this that seems interesting to us is that it requests SASL_CB_USER from interact, which basically checks the user is root. The code then makes the most elegant use of a goto that I’ve seen in a long while, skips a whole load of interactive code, and returns the default:

use_default:
		/* input must be empty */
		interact->result = (dflt && *dflt) ? dflt : "";
		interact->len = strlen( interact->result )

This says to me that the interaction callback function could be reduced to:

int do_interact(
	LDAP *ld,
	unsigned flags,
	void *defaults,
	void *in )
{
	sasl_interact_t *interact = in;
	lutilSASLdefaults * sasl_defaults = (lutilSASLdefaults *)defaults;
	const char *dflt = interact->defresult;
	dflt = sasl_defaults->authzid;
	interact->result = (dflt && *dflt) ? dflt : "";
	interact->len = strlen( interact->result );
	return LDAP_SUCCESS;
}

But now I see that the defaults passed in are defined external to the ldap code. We can drop all of the pointers except the one to the authzid. In fact, we can just make this a char *.

Here’s the code in a functional state. It leaks memory, which would need to be cleaned up for a real application.

#include <sasl.h>
#include <ldap.h>
#include <stdio.h>

int do_interact(
		LDAP *ld,
		unsigned flags,
		void *defaults,
		void *in )
{
  sasl_interact_t *interact = in;
  char * sasl_defaults = (char  *)defaults;
  const char *dflt = interact->defresult;
  dflt = sasl_defaults;
  interact->result = (dflt && *dflt) ? dflt : "";
  interact->len = strlen( interact->result );
  return LDAP_SUCCESS;
}

int main(){
  printf("Start\n");
  LDAP *ldap;
  int rc;
  struct berval *servercredp;
  unsigned long version = LDAP_VERSION3;
  LDAPMessage *res;
  char ** vals;
  int message_count;
  int i,j,k;

  if (( rc = ldap_initialize(&ldap,  "ldapi:///")) != LDAP_SUCCESS)
    {
      perror ( NULL );
      return( 1 );
    }

  rc = ldap_set_option(ldap,
		       LDAP_OPT_PROTOCOL_VERSION,
		       (void*)&version);
  char * defaults;
  char * sasl_mech = "EXTERNAL";
  char * sasl_realm = NULL;
  char * sasl_authc_id = NULL;
  char * sasl_authz_id = NULL;
  struct berval	passwd = { 0, NULL };
  unsigned	sasl_flags = LDAP_SASL_AUTOMATIC;
  LDAPControl	**sctrlsp = NULL;

  ldap_get_option( ldap, LDAP_OPT_X_SASL_AUTHZID, &defaults );

  char *	binddn = NULL;
  rc = ldap_sasl_interactive_bind_s( ldap, binddn, sasl_mech,
				     sctrlsp,
				     NULL, sasl_flags, do_interact, defaults );

  if ((rc =  ldap_search_ext_s
       (
	ldap,
	"cn=config",
	LDAP_SCOPE_SUBTREE,
	"(objectClass=*)",
	NULL,
	0,
	NULL,
	NULL,
	NULL,
	0,
	&res ) != LDAP_SUCCESS))
    {
      printf("ldap_search  failed with 0x%x.\n",rc);
      perror ( NULL );
      return( 1 );
    }
  LDAPMessage *entry = ldap_first_entry( ldap, res );

  int entry_count = ldap_count_entries(ldap, res);
  for (i = 0 ; i < entry_count; i++){
    printf("dn: %s\n",ldap_get_dn(ldap, entry));
    BerElement * ber;
    char * attribute = ldap_first_attribute(ldap,entry, &ber);
    while(attribute){
      printf ("attribute = %s\n",attribute);
      attribute = ldap_next_attribute(ldap,entry, ber);
    }
    ber_free(ber,0);
    entry = ldap_next_entry(ldap, entry);

  }
  return 0;

}

Note: The reason I do SASL using a -I option in the makefile instead of sasl/sasl.h is that the code formatter is messing it up.

Dan Walsh: SELinux problems on Fedora 17.

2012-02-13T20:35:38+00:00

Anyone that has tried Fedora 17 over the last couple of days, might have noticed SELinux going nuts and blocking logins.

systemd had a bug which was causing transitions to break.

The way the system is supposed to work is during boot systemd reads in the policy file on disk and then loads policy into the kernel.
This causes all processes at that are running to be labeled kernel_t.

systemd then reads the label on its image file /sbin/systemd (init_exec_t) and the label that it is currently running as (kernel_t), then it asks the kernel what label would the /sbin/systemd process get if kernel_t executed it. The answer would be init_t, and then systemd is supposed to set the current label to init_t. From that point on all processes started by systemd would transition to their proper domains.

Well just before systemd/Fedora 17 Alpha was about to be released. Systemd changed the location of its executable from /bin/systemd to /usr/lib/systemd/systemd. But they never changed the checking code. We fixed policy to look at the new location and labeled /usr/lib/systemd/systemd correctly, but when systemd checked for the label of /bin/systemd, there was no file and systemd just continued running as kernel_t. Since there are few rules for transitions of kernel_t to any other label, most of the system was labeled as kernel_t. Finally when a user logged in via gdm or login or sshd, they were running as kernel_t and the code transitioned them to abrt_t, one of the few domains kernel_t will transition to.

systemd-42-1.fc17 fixes this problem, so if you update to this systemd or later, you should be able to run your system in enforcing mode.

Needless to say, we have been flooded with bug reports...

Adam Young: DNS Managers in FreeIPA

2012-02-13T02:48:21+00:00

The Domain Name System (DNS) is an essential part of systems management. If you need to manage multiple physical hosts you’d really benefit by a degree of control of some subset of DNS. With Virtual machines, the sheer number of hosts created demand a responsive DNS. Kerberos, X509 and other security mechanisms require a proper DNS configuration. Yet, for many organizations, DNS is locked down by IT to a very static set of records. Earlier articles discussed User Groups, Host Groups, and Netgroups. The final installment in this series discsusses how to delegate DNS Zone management in FreeIPA.

First, create a Zone for the project, and one DNS record

[root@f16server ~]# ipa dnszone-add beowulf.younglogic.com
Authoritative nameserver: f16server.ayoung.boston.devel.redhat.com
Administrator e-mail address [hostmaster.beowulf.younglogic.com.]:
Zone name: beowulf.younglogic.com
Authoritative nameserver: f16server.ayoung.boston.devel.redhat.com.
Administrator e-mail address: hostmaster.beowulf.younglogic.com.
SOA serial: 2012110201
SOA refresh: 3600
SOA retry: 900
SOA expire: 1209600
SOA minimum: 3600
Active zone: TRUE
Dynamic update: FALSE
[root@f16server ~]# ipa dnsrecord-add
Zone name: beowulf.younglogic.com
Record name: www1
[A record]: 10.10.2.1
[AAAA record]: feed:0123::babe
Record name: www1
A record: 10.10.2.1
AAAA record: feed:0123::babe

Here’s the LDAP details of what we just created:

[root@f16server ~]# ipa dnszone-show beowulf.younglogic.com --all --raw
dn: idnsname=beowulf.younglogic.com,cn=dns,dc=f16server,dc=ayoung,dc=boston,dc=devel,dc=redhat,dc=com
idnsname: beowulf.younglogic.com
idnssoamname: f16server.ayoung.boston.devel.redhat.com.
idnssoarname: hostmaster.beowulf.younglogic.com.
idnssoaserial: 2012110201
idnssoarefresh: 3600
idnssoaretry: 900
idnssoaexpire: 1209600
idnssoaminimum: 3600
idnszoneactive: TRUE
idnsallowdynupdate: FALSE
nsrecord: f16server.ayoung.boston.devel.redhat.com.
objectclass: top
objectclass: idnsrecord
objectclass: idnszone

Notice that the A and AAAA records are not visible in the DNS Zone object. Since we are not just modifying values of attributes, we can’t perform the same type of delegation as we did with User Groups, Host Groups or Netgroups. Lets take a look at the LDAP details of the Record.

[root@f16server ~]# ipa dnsrecord-show beowulf.younglogic.com www1 --all --raw
dn: idnsname=www1,idnsname=beowulf.younglogic.com,cn=dns,dc=f16server,dc=ayoung,dc=boston,dc=devel,dc=redhat,dc=com
idnsname: www1
arecord: 10.10.2.1
aaaarecord: feed:0123::babe
objectclass: top
objectclass: idnsrecord

A and AAAA records that have the same idnsname go into the same LDAP object. PTR and CNAME records would all be put into additional attributes of this object if they, too, had the same idnsname. This LDAP object is a subordinate object to the Zone, beowulf.younglogic.com.

Thus, we can use the Subtree permission type to manage access to this resource. The subtree is the distinguished name (DN) of the DNS Zone.

[root@f16server ~]# ipa permission-add 'beowulf-dns-modify'  --permissions=add,delete
[Attributes]:
[Type]:
[Member of group]:
[Filter]:
[Subtree]: idnsname=beowulf.younglogic.com,cn=dns,dc=f16server,dc=ayoung,dc=boston,dc=devel,dc=redhat,dc=com
[Target group]:
-------------------------------------
Added permission "beowulf-dns-modify"
-------------------------------------
  Permission name: beowulf-dns-modify
  Permissions: add, delete
  Subtree: ldap:///idnsname=beowulf.younglogic.com,cn=dns,dc=f16server,dc=ayoung,dc=boston,dc=devel,dc=redhat,dc=com

We could use the objectname and cn as we did before, but subtree is better documentation to our intent.

Again, we need to add the permission to the privilege.

[root@f16server ~]# ipa privilege-add-permission beowulf-manage --permission=beowulf-dns-modify
  Privilege name: beowulf-manage
  Description: Manage the Assets of the Beowulf project
  Permissions: beowulf-manage, beowulf-manage-group, beowulf-hostgroup-modify,
               beowulf-netgroup-modify, beowulf-dns-modify
  Granting privilege to roles: beowulf-managers
-----------------------------
Number of permissions added 1
-----------------------------

Test it out with the admiyo account (that already has the Role beowulf-managers. This time, we’ll add both an A and AAAA record, which are managed by the same object in BINDs LDAP backend.

[root@f16server ~]# ipa privilege-add-permission beowulf-manage --permission=beowulf-dns-modify
  Privilege name: beowulf-manage
  Description: Manage the Assets of the Beowulf project
  Permissions: beowulf-manage, beowulf-manage-group, beowulf-hostgroup-modify,
               beowulf-netgroup-modify, beowulf-dns-modify
  Granting privilege to roles: beowulf-managers
-----------------------------
Number of permissions added 1
-----------------------------
[root@f16server ~]# kinit admiyo
Password for admiyo@F16SERVER.AYOUNG.BOSTON.DEVEL.REDHAT.COM:
[root@f16server ~]# ipa dnsrecord-add
Zone name: beowulf.younglogic.com
Record name: mail1
[A record]: 10.10.2.3
[AAAA record]: feed:babe:beef::cafe
  Record name: mail1
  A record: 10.10.2.3
  AAAA record: feed:babe:beef::cafe

These four articles have attempted to show how the access controls of FreeIPA allow a system administrator to delegate specific actions to power users in their organization. From the simplest and most targeted of Target Groups, through simple and then more complex filter queries, then finally subtree queries. While FreeIPA can abstract you away from having to understand LDAP, it does not prevent you from doing so. Instead, LDAP know how built on top of the structure provided with FreeIPA can help to craft secure and flexible delegation policy.