Func, Fedora Unified Network Controller, allows us to send commands for remote execution in a set of pre-configured hosts. More, it allows us to choose which machines we want to address using shell globs. This, and more, is done securely over SSL. Func facilitates remote administration.

Func is a Fedora project whose general architecture is based on two parties: Func itself and Certmaster. Certmaster is responsible for authentication and encryption using SSL certificates. Certificates are identity proofs. And, from my knowledge, (correct me) they are little more than a signature (private key encryption of an hash) attached to a cryptographic public key. Certmaster application is composed by a client and a daemon capable of requesting and serving SSL certificates. This enables a master machine to communicate with a slave over SSL.

On top of this comes Func: it is also a built on client-server style and enables administrators to build an infrastructure of slave machines running the daemon funcd. This daemon listens on a port for requests from a certain master machine. In fact, the SSL scheme behind it lets us sleep tight at night knowing that those slaves will only reply to the master and not some fake.

The master is where the all-powerful sysadmin is logged in From that machine, the sysadmin can issue commands for execution by the slaves at the same time. Even cooler, he can address those machines in the following manner:

"*fe.up.pt"

Meaning all the machines in the “fe.up.pt” domain under my control. How cool is that?

Func is python, and has a python API so, besides using Func directly, we can even build our own customized scripts.

Installation…

I tested this in CentOS 5. I think Func and Certmaster are in the EPEL repo.

This, in fact, little more than what can be found in the official Func page.

On the master:

Install Func and Certmaster. Certmaster gets pushed by Func on installation.

Certmaster daemon will be running on the master machine, making it possible for the slaves (called minions) to request certificates.

$ yum install func
$ /sbin/chkconfig --level 345 certmaster on
$ /sbin/service certmaster start

On the slave machines:

On the minions, the funcd will be running, accepting requests from func client and running commands. Besides this, func will try to request certificate signing from the master. For this to work, we’ll need to indicate the master’s address on the certmaster configuration file.

$ yum install func

Edit the /etc/certmaster/minion.conf file and change the address of your master machine. For example:

# configuration for minions
[main]
certmaster = master.fe.up.pt
certmaster_port = 51235
log_level = DEBUG
cert_dir = /etc/pki/certmaster

Now, put the funcd running at boot and start it.

$/sbin/chkconfig --level 345 funcd on
$/sbin/service funcd start

Also, you need to open ports on iptables. The master machine must have port 51235 open, and the minions must have port 51234 open.

Working

Now we have the environment set.

Before starting to send commands to slaves, we need to “sign” them first. Issue the following command from the master to list the slave machines. If everything is ok, you’ll see all the slave machines where you’ve just installed func.

$ certmaster-ca --list

Once you’ve seen the machines that are ready to be signed, you can sign them:

$ certmaster-ca --sign slave1.fe.up.pt
$ certmaster-ca --sign slave2.fe.up.pt
$ ...

Example

Now, you’re ready to send commands. Let’s imagine you want to send a message to all logged users on the slaves, using wall command:

$ func "*.fe.up.pt" call command run "wall 'Hello users! Machine will go down for reboot in 1 minute! Save you work!'"

This is a simple example. You can use more complex globbing to address specific machines. See https://fedorahosted.org/func/wiki/CommandLineGlobbing.

About provisioning

If you want to integrate minion installation with kickstart for example, it’s fairly simple, as you only need to install packages and change a line of the config file.

You can run into some problems if you happen to kickstart a minion machine, both in the master and slave. This is because in the master there will be a CSR inconsistent with the new machine. And in the minion, because funcd automatically retrieves the certificate at boot, funcd will have a wrong certificate, one referring to the previous state of the machine before re installation. You can solve this by cleaning SSL keys and such in the minion and cleaning the certificate request on the master:

# on the new, kickstarted machine
$ service funcd stop
$ rm -rf /etc/pki/certmaster/*
# on the master
$ certmaster-ca --clean <hostname_of_the_kickstarted_machine>
# again, on the slave
$ service funcd start
# on the master again
$ certmaster-ca --sign <hostname_of_the_kickstarted_machine>

All this is just to clean certificates and certificate requests form both ends.

This can be avoided if, immediately before restarting the minion to a re installation,  we clean its respective certificate request in the master with:

$ certmaster-ca --clean <hostname>

This way, when the minion boots up with the funcd daemon running, it will reach a consistent state.

Still, you’ll have to issue the –sign command.

References

• https://fedorahosted.org/func/

He’s called Jordão and there’s a small chance he’s actually a she… I don’t know…

The Cage

Jordão Resting

Jordão facing me

Jordão being held...He does not like it...heads will roll...!

Jordão dating a gal

]]> http://blog.andrecardoso.eu/2010/08/i-haz-bunny/feed/ 0 http://blog.andrecardoso.eu/2010/08/i-haz-bunny/ http://feedproxy.google.com/~r/andrecardoso/bYoR/~3/4xsSjyIhRPY/ http://blog.andrecardoso.eu/2010/08/openafs-encryption-and-kerberos-v/#comments Mon, 16 Aug 2010 01:41:21 +0000 belerophon http://blog.andrecardoso.eu/?p=513 Context

It was our intention to build a secure network, with single sign-on mechanisms. With ‘secure’ we mean secure authentication and transmission of data. Kerberos solves the problem of secure authentication using a shared secret key architecture. In fact, while authenticating principals passwords are never sent over the cables. Authentication is based upon the ability of the principal of decrypting some piece of information.

Kerberos also solves the problem of mutual authentication: each service (server) and consumer must  know for sure that they are communicating with authorized parties and not with fakes. This is cleverly solved using the Needham-Schroeder scheme. This algorithm enables two parties to share a session key, securely. The session key can be further used to protect communications between them. In particular, Kerberos introduces the concept of Authenticators. These are, basically, principal identifiers and timestamps. When a client initiates communication with a service, sends him … well it sends him a butload of things but the important thing is that it sends him a Authenticator encrypted with the session key that both will use. However, the service cannot decrypt it yet, because it has no access to the session key itself. To obtain the session key, he first has to decrypt another part of the message sent by the client, which is the session key encrypted with the key that only he and the Ticket Granting Service share. Now, the service is prepared to decrypt the Authenticator sent by the client and reply to him with a new Authenticator which now contains the original timestamp plus 1. This goes, once again, encrypted using the same session key. This can somewhat be seen in the pictures below. They were taken from the course I’ve attended last year on Computer Systems Security.

Authentication protocol used in Kerberos. Simplified. Taken from the lecture notes of Computer Systems Security: http://web.fe.up.pt/~jmcruz/ssi/acetat/4-autentica.pdf

Service request phase. Simplified. Taken from the lecture notes of Computer Systems Security: http://web.fe.up.pt/~jmcruz/ssi/acetat/4-autentica.pdf

Wrapping up, mutual authentication is achieved, from the service side, by matching the information found in the Authenticator against the information found in the ticket (crafted by the TGS) and the network information. If everything matches, the client is authenticated. The client authenticates the server when it receives from it the proper authenticator in reply to its own.

Problem

By now we have authentication and, as a sub-product of kerberos system, communication encryption. OpenAFS can now enter here as a means to distribute, for example, the home directories of users over the network (network login facilities…). OpenAFS has the advantage of being a natively kerberized application. The problem is the type of encryption supported by it.

If I’m not mistaken, AES is accepted as the strongest encryption algorithm and is also supported by Kerberos. However, by what I know, there are two problems with OpenAFS: it only supports des-cbc-crc:v4 principal keys, which means authentication is done using a weak encryption protocol. The other problem is that communication between afs clients and servers get encrypted using something even weaker: fcrypt.

In fact, this is something that confuses me: I thought that encryption of any two parties “talking” kerberos was done using the session key given by the TGS. But it seems that applications like OpenAFS bypass this, using their own encryption scheme. Or maybe the session key is used only for the mutual authentication part. In this case, what type of encryption protocol is used those messages? This whole thing about encryption leaves me confused…if someone cares to shed some light, it would much appreciated

But as far as I know, in the current network design that we were trying to mount (kerberos, ldap, openafs) the weak link is OpenAFS, because all the other principals can use of AES encryption type.

Nonetheless, this whole scheme of Kerberos plus OpenAFS plus OpenLDAP is just great to whom seeks to secure a smaller network within unsecured networks.

References

• http://docs.openafs.org/Reference/8/asetkey.html
• http://users.surfvi.com/~ota//fcrypt-paper.txt
• http://docs.openafs.org/Reference/1/fs_setcrypt.html
• http://web.mit.edu/kerberos/krb5-1.8/krb5-1.8.3/doc/krb5-admin.html#Supported%20Encryption%20Types
• http://en.wikipedia.org/wiki/Needham-Schroeder_protocol
• http://en.wikipedia.org/wiki/Kerberos_%28protocol%29#Client_Service_Authorization
• http://web.mit.edu/Kerberos/dialogue.html
• http://openafs.org/
• http://web.mit.edu/kerberos/
• http://web.fe.up.pt/~jmcruz/ssi/acetat/4-autentica.pdf

As the previous post with my first presentation seems to have vanished from my blog (VPS problems :S), I leave here the first presentation as well.

Update (31/07/2010):

The term has ended, and I’ve finished the report for the course dedicated to prepare us for the thesis development on the next school term.

So, I leave here the link for the report, to complete the documentation:

ftp://andrecardoso.eu/ftp/PDIS/report.pdf

(It’s far from perfect though:)

Our program who art in memory, Hello be thy Name. Thy Operating System come, thy Commands be done, at the Printer as it is on the screen. Give us this day our daily data, and forgive us our I/O Errors as we forgive those whose Logic Circuits are faulty. Lead us not into frustration, and deliver us from Power Surges. For Thin is the Algorithm, the Application, and the Solution, looping forever and ever.

Return.

(Credits go to the author, whom I don’t know. It is a nice prayer though..:P)

Then, if you look to the “Getting Started Guide for Mac“, they tell you to make sure your gpu is supported and then compile the sample code provided in /Developer/GPU Computing/C/.

This part failed for me, because I kept getting the “no table of contents” error when the linker tried to link against the libraries, namely the libcutil_i386.a.

I’ve managed to compile the samples after googling for this and reading the posts in this nvidia forum. So, following some recommendations found in the forum I opened the file common.mk found in /Developer/GPU Computing/C/common and changed lines 39 and 306 to the following:

39: SNOWLEOPARD = $(strip $(findstring 10.6, $(shell egrep "<string>10\.6\.3" /System/Library/CoreServices/SystemVersion.plist)))
306: LINKLINE  = ar rucvs $(TARGET) $(OBJS)

Note the different version number of the OS and the s switch in the LINKLINE, which forces the creation of an index.

Then I tried to make clean and make again, but the error persisted. This time, I read this and found the solution, which is to run the ranlib command in the directories containing the libraries used during the compilation of the samples:

cd "/Developer/GPU Computing/C/lib"
ranlib *.a
cd "/Developer/GPU Computing/shared/lib"
ranlib *.a

By the way, apparently, the ranlib command creates a table of contents…

This got me rid of the errors.

Hope this helps.

References

• http://developer.nvidia.com/object/cuda_3_0_downloads.html
• http://forums.nvidia.com/index.php?showtopic=79189
• http://forums.nvidia.com/index.php?showtopic=105940&st=20&p=989833&#entry989833

So…there is a fine package which provides a nice style that mimics the Europass style: http://www.ctan.org/tex-archive/help/Catalogue/entries/europecv.html.

I think TexLive 2009 already has this package, but if not you can just take the style and put it in the directory of the document you’re creating, and use it when defining the documentclass.

Next I show you my complete preamble:

\documentclass[utf8x,helvetica,narrow,english,logo,totpages, booktabs]{europecv}
\usepackage[T1]{fontenc}
\usepackage{textcomp}
\usepackage{graphicx}
\usepackage[english]{babel}
\usepackage{geometry}
\geometry{verbose,a4paper,tmargin=1.27cm,bmargin=2cm,lmargin=1cm,rmargin=1cm}
\usepackage{microtype}
\renewcommand{\ttdefault}{phv}
\ecvname{André dos Santos Cardoso}
\ecvnationality{Portuguese}
\ecvaddress{my address....}
\ecvtelephone[1234567]{1234567}
\ecvemail{email\\&another email}
\ecvdateofbirth{01/10/1987}
\ecvgender{Male}
\ecvpicture[width=90px]{eu_140x200}
\ecvbeforepicture{\ecvspace{-2.7cm}\centering}
\ecvafterpicture{\ecvspace{-1.5cm}}

After the usual inclusion of packages and so, I wrote my personal info using the appropriate commands defined in the europass package. All this information can then be printed using another command: \ecvpersonalinfo.

Depending on your picture (and whether or not you decide to put one) you may have to play with the number in \ecvafterpicture and \ecvbeforepicture. More details can be found on the documentation.

Now, I find it easier to update and get around all that I’ve wrote if I divide my CV in logical sections and different files. So, using the \include command, the rest of the master file gets pretty easy to read:

\begin{document}
\begin{europecv}
\ecvpersonalinfo % prints the personal info, defined in the preamble
\input{experience.tex}
\input{education.tex}
\input{skills.tex}
\input{aditional.tex}
\end{europecv}
\end{document}

The actual information about us gets thrown into each of those files, and every file uses the same format. It’s a collection of sections and items. For example, let’s take the file experience.tex, it will have only one section, Work Experience, and as many blocks of items as jobs you’ve done:

\ecvsection{Work Experience} % the section %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\ecvitem{Dates} %%%%%%%%%%%%%%%%%%%%%%% the first block
{
 bla bla bla date
}
\ecvitem{Occupation or position held}
{
 bla bla you position during the job
}
\ecvitem{Main activities and responsibilities}
{
bla bla what you've done
}
\ecvitem{Name and address of employer}
{
bla bla where you've done it
}
\ecvitem{Type of business or sector}
{
bla bla category of the business
}
\ecvitem{}{} % to give some vertical space before the next block
\ecvitem{}{} % to give some vertical space before the next block
\ecvitem{Dates} %%%%%%%%%%%%%%%%%%%%%%% the second block
{
bla bla bla date
}
\ecvitem{Occupation or position held}
{
 bla bla you position during the job
}
\ecvitem{Main activities and responsibilities}
{
bla bla what you've done
}
\ecvitem{Name and address of employer}
{
bla bla where you've done it
}
\ecvitem{Type of business or sector}
{
bla bla category of the business
}
\ecvitem{}{} % to give some vertical space before the next block
\ecvitem{}{} % to give some vertical space before the next block
% ... and it keeps going while you have jobs 

So, you see, the information gets formatted using \ecvsection and \ecvitem. In fact, it is not quite true (but almost) because the europass has that language table: for this the package has also some special commands to build the table and fill it with the correct values (more on this in the documentation).

I will leave here the blocks and titles I’ve used for the other files:

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% file education.tex
\ecvsection{Education and Training} %% the section
\ecvitem{Dates}
{
bla bla
}
\ecvitem{Title of qualification awarded}
{
bla bla
}
\ecvitem{Principal subjects/occupational skills covered}
{
bla bla
}
\ecvitem{Name and type of organisation providing education and training}
{
bla bla
}
\ecvitem{ Level in national or international classification}
{
bla bla
}
\ecvitem{}{} % to give some vertical space before the next block
\ecvitem{}{} % to give some vertical space before the next block
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% file skills.tex
\ecvsection{Personal skills and competences}
\ecvmothertongue{Portuguese} % the language table
\ecvlanguageheader{(*)}
\ecvlanguage{English}{\ecvAOne}{\ecvAOne}{\ecvAOne}{\ecvAOne}{\ecvAOne}
\ecvlastlanguage{French}{\ecvAOne}{\ecvAOne}{\ecvAOne}{\ecvAOne}{\ecvAOne}
\ecvlanguagefooter{(*)}
\ecvitem{}{}
\ecvitem{}{}
\ecvitem{Social skills and competences}
{
bla bla
}
\ecvitem{Social skills and competences}
{
bla bla
}
\ecvitem{Computer skills and competences}
{
bla bla
}
\ecvitem{}{}
\ecvitem{}{}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% file aditional.tex
\ecvsection{Additional information}
\ecvitem{}
{
}

Before closing this post, I’d like to point out a kind of a trick you can use inside the \ecvitem block to build lists. The \ecvitem works like two columns in a tabular environment, so you can do things like these:

\ecvitem{Bla bla bla bla}
{
\\&-- First item\\
&-- Second item\\
&-- Third item\\
&-- Fourth item
}

This puts 4 lines in the second column. I think that in the CV this achieves a visually better style than using an itemize environment.

I have to say thanks to João Azevedo, because he’s the one who loaned me his CV in LaTeX format, using the europecv package. Credits go to him.

Hope this is helpful:)

The transition process encompasses the creation of a single sign-on system using MIT KerberosV, although this is not the primary objective: as the network is insecure, built inside the wider network of the College Campus without a router behind it, Kerberos provides a very good authentication and encryption mechanism. The ultimate goal is to encrypt every single communication over the network, thus kerberizing all the network services.

The details of the protocol still evade me a little bit, but the important thing to retain is that the network has a single(or most important) point of failure which is the KDC, Key Distribution Center: this is a server (in fact, it is composed by two, but lets ignore that fact), which shares a Key with every user and machine in the network. This is a point of failure because if the machine where the KDC reside gets compromised, the entire security of the network get compromised as well.

The protocol

So, the authentication of a user is pretty straight-forward: the client enters a pass, hashes it, sends it the the KDC, the KDC compares it to the entry he has in its database. The most interesting part it that if the the authentication is successful, the KDC sends back a session Key, duplicated in two messages: the firs is encrypted with the client’s own password, and the second comes encrypted with another server’s (I’ve skipped a few steps, but let’s imagine this server is one which the user wants to communicate, securely, with) key. Recall that KDC shares secret keys with everyone in the network, so it is capable of creating messages that can only be decrypted by certain machines or users….

At this moment, the user, that may want to communicate with a FTP server, has in his possession 2 messages. He can decrypt one, and from that action he get’s a session key to communicate with the said FTP server. What he is going to do with the second message is simply pass it to the FTP server. Recall, that this server shares a key with KDC, and the message he is about to receive is encrypted with that same key. So, the FTP server can decrypt that message, and gets the same session key that the user previously got. At this moment,  they can both communicate securely over an insecure network, using the session key produced by the KDC.

Once we get to know a little more about the protocol (we need more than what I just described) we are capable of acknowledging why this provides a single sing-on system.

The wikipedia page may provide a little help on this.

So, for now, my job is to implement this system in same machines and document the process, so it can be reproducible when the time comes to move everything to CentOS.

I’m confident that this will let me learn a lot about networks…:)

Thanks.

…

It can’t be good…