Neuromancipation

This is a walkthrough of setting up agent forwarding to allow transparent access to computers on the other side of a gateway.  The main reference is the awesome article An Illustrated Guide to SSH Agent Forwarding; see also SSH and ssh-agent for a more Unix-like approach.  We will suppose that we are on the machine HOME, and that we want transparent access to the machine TARGET which we can only access via the machine GATEWAY.  We proceed as follows:

1. Generate a public/private key pair on HOME using ssh-keygen -t rsa -b 3072 (we need a bitsize of 3072 when using AES128).
2. Copy the file HOME:.ssh/id_rsa.pub to the files {GATEWAY,TARGET}:.ssh/authorized_keys.
3. Add the text command="sh -c 'ssh username@TARGET ${SSH_ORIGINAL_COMMAND:-}'" to the beginning of the file GATEWAY:.ssh/authorized_keys.  (The SSH_ORIGINAL_COMMAND business is apparently needed for svn to work. It’s also supposed to make scp work, but unfortunately it doesn’t.) This is called a forced command.
4. Finally add the following to the file HOME:.ssh/config, which will allow easy access to TARGET and, importantly, enable agent forwarding:
   

   Host nickname_for_TARGET
   Hostname TARGET
   User username_for_TARGET
   ForwardAgent yes

Now to use this from HOME, we run ssh-agent and ssh-add in a terminal, and then running ssh nickname_for_TARGET should dump us directly onto TARGET.

In case I end up needing to implement a memory pool in C, I should probably read:

• The Memory Management Beginner’s Guide; and consider using or consulting the
• Memory Pool System Project.

So I’m writing a library that is processing a lot of raw data, and does some string handling (mainly for opening files and the like).  So I want to know what the best choice of character type is for each kind of data.  The library (written by someone else) uses unsigned chars exclusively, which, in particular, means we get lots of warnings when the unsigned char strings are passed to the standard library functions.  Here is what I’ve found through Google:

• One guy on this thread recommends char for all strings and unsigned char for raw data.
• This link says that sizeof(char) == 1 always, though there exists a constant CHAR_BIT in limit.h which, while normally equal to 8, can sometimes be bigger. This shouldn’t be an issue for me.
• These two links say that char should be used for all string literals, and that either unsigned char or signed char should be used for 8-bit integer values.

In summary, I think I’ll define a rawbyte_t type (typedef unsigned char rawbyte_t) and use that whenever I’m handling raw data, and use plain char for things that are definitely strings.

(As a side note, this guy reckons it’s fine not to cast the result of a malloc() call.  I’m not entirely sure I’m convinced.)

In fact, when a function can take a pointer to what is essentially an arbitrary block of memory, it’s considered good practice to accept a void* and then cast it to (what I have called) a rawbyte_t* inside the function.

So I need to write secure code. This post will accumulate some of the resources I’ve found so far.

This link explains the need to be wary of compiler optimisations when dealing with sensitive data. This is related to the need to clear sensitive data.

Some lists of rules:

• Build Security In (from the DHS)
• CERT C Secure Coding Standards
• Secure Programming for Linux and Unix HOWTO
• (New!) A Taxonomy of Coding Errors that Affect Security
• (New!) Common Weakness Enumeration
• (New!) SANS Top 20 Internet Security Weaknesses

Microsoft now has a list of functions from the C runtime that are banned. Most of those listed are Microsoft specific, but there are a few POSIX ones.  I’ll list them, and also alternatives when I can think of them.  Note that the alternatives that Microsoft have proposed are considered by some to be an attempt at vendor lock in.  No surprises there.  But, perhaps surprisingly, the glibc guys have rejected a few alternatives too.  (NB: Of course, the wide character versions (where applicable) were all banned too.)

• strcpy() — strncpy() (MS banned this too, see below) or strlcpy() (glibc folks don’t approve of this one, hence they don’t implement it)
• strcat() — strncat() or strlcat() (same story as above)
• sprintf() — snprintf()
• vsprintf() — vsnprintf()
• strncpy() — strlcpy()?
• strncat() — strlcat()?
• strtok() — ?
• scanf() — ?
• gets() — ?
• alloca() — ? Having variable length arrays on the stack is probably a bit dangerous.
• strlen() — ? This doesn’t seem to be a problem in itself, rather it’s use with other str* functions can cause problems.

When using the “n” string functions, make sure you’re using them properly (see this and also this for a comment on the inefficiency of strncpy()).

Although not yet officially on Microsoft’s list, apparently memcpy() is due to be dumped too.  A workaround for GCC users has been proposed.

For the time being, I want to simulate the old central repository setup with Mercurial.  I have a server for my central repo, say server.com.  I’ve cloned my repo using

hg clone ssh://me@server.com/repo

I make some local changes, commit them to the local working directory, then push them to server.com with

hg push ssh://me@server.com/repo

The changes aren’t there yet: I need to ssh to server.com and run

hg update

within repo.  I should then be able to acces the new version from a different location (assuming an existing working directory) with

hg pull ssh://me@server.com/repo

hg update

Yay!  All the functionality of svn with twice the number of commands!