Archive for the ‘Identity Management’ Category

WordPress: Quick directions for adding OpenID

Sunday, September 20th, 2009

Adding OpenID to your WordPress site is a good idea for a number of reasons. One is visitors to your site can use their OpenID to leave comments.

Secondly, you can use your own blog to provide your OpenID credentials to other sites that accept OpenID credentials. Your WordPress site, in effect, becomes your personal OpenID Provider!

Here is what you need to do to get OpenID on your site. (For this tutorial, I am using WordPress version 2.7).

1. Install XRDS-Simple Plug-In.

To do this, you download the zip file from the link above, unzip, upload this folder to server’s “/wp-content/plugins/” directory.

Go into WordPress as admin, go to Plug-in page. Activate XRDS.

Activate the plugin through the ‘Plugins’ menu in WordPress.

2. Install OpenID Plug-in.

To do this, you download the zip file from the link above, unzip, upload this folder to server’s “/wp-content/plugins/” directory.

As admin, go to Plug-in page. Activate Open-ID.

3. Configure.

On the left-hand side of the page, look for the Settings Tab. Look for “Open-ID” under that. Click on that. Set your preferences.

Note, here you can set your comment forms to allow OpenIDs. Keep in mind, as someone noted, that setting the blog to allow OpenID-authored comments to bypass spam filters is probably not a good idea.

Also note, you can begin to use your site as your own personal OpenID provider. As the configuration page notes:

Authorized accounts on this blog can use their author URL (i.e. http://YOUR BLOG ADDRESS/?author=1) as an OpenID. The Blog Owner will be able to use the blog address (http://YOUR BLOG’S ADDRESS) as their OpenID. If this is a single-user blog, you should set this to your account.





Unix: The Basic Mechanics of File Permissions

Wednesday, April 22nd, 2009

Unix is a multi-user system. As such, every process that runs and every file that is stored must have an owner, or user-account. Conversely, each time a user tries to interact with a program or file, Unix checks to see if the user has permission before letting him/her proceed with the action.

The owner of currently running programs can be checked through the ps command. At the command prompt type “ps-aux” and you’ll get a list of programs currently running. The last two entries may look something like:

henry 32186 0.7 0.7 5604 3020 pts/0 Rs 06:58 0:00 -bash
henry 32202 0.0 0.2 2644 1012 pts/0 R+ 06:58 0:00 ps -aux

The last two actions carried out were done by user “henry”–namely opening the shell (-bash) when logging in (an automatic procedure; the shell provides the command line), and the running of “ps -aux” itself.

For files and directories, user permissions can be found by typing in the list command, with the option to show details (“ls -l”) at command prompt. You should get something like this:

-rw-r–r– 1 henry henry 6 2009-03-29 22:10 test.txt
-rwxr–r– 1 henry henry 32 2009-03-29 22:15 text.txt

In this listing, we see the information for two files (“test.txt” and “text.txt”), one on each line. The user permissions are on the left (the series of dashes & letters, or flags). Right after that is the file owner (“henry”) and the name of the group that file belongs to (more on that later, maybe). The size of the file and when it was created is also included in that listing.

Deciphering the Permission Set

Each one of the 10 flags (“drwxrxwrxw”) designates whether or not a designated party has a specific permission to do something with the file. The rest of this section will break down what each permission means.

To understand the full set of permissions, break them into four subsets, reading left to right:

Position 1: This indicates whether or not the file is a directory (if it is, then there is a “d”–if it is not a directory, then “-”).

Positions 2-4: This is the set of permissions allotted to the owner of the file.

Positions 5-7: This is the set of permissions allotted to the group that owns the file.

Positions: 8-10:These are the permissions for everyone else who is not the owner of the file, nor belongs to the group that owns the files (“Others“).

In recap, reading left to right (after the directory key), you are reading the read-write-execute permissions for owner-group-other. Summarily, the permission set runs from lesser to greater degrees of control of a file, and from specific to more general possible users of the file.

Each of these three sets of letters comes in the same format. Reading each block of three left to right, you could see, in this order:

r: The right to read the file.

w: The right to write to the file, meaning to make changes to the file.

x: The right to execute the file. If the file consists of code that can be executed by the machine, and if the “x” is present, then the individual can task the computer with executing the code within the file (or, rather, the file is the program).

If the letter is present in the designated spot, then that permissions is granted. if a blank (“-”) is in the place, then there is no permission.

As an example, if a file has the permissions:

-rwxrw-r–

This means the owner of the file read, write, or execute the file. The group can read and write to the file, but not execute it. And everyone else can read to the file, but not execute it.


To change the permissions of a file, use the chmod command on the command line. chmod is an abbreviation for “change mode”

The basic format for chmod is this:

chmod [Changes to be made] [file]

For simplicity, I’m leaving out the ability to designate options and to concatenate the commands. See the manual page for more details.

The “Changes to be made” space above, you want to format the changes to be made in this way:

[who the changes will apply to] [The action to be carried out] [The new permissions]

Who the changes will apply to will be one of four groups

u: The owner of the file.
g: Other users in the file’s group.
o: All other users.
a: Everyone (u and g and o)

Note that “other” users is not quite the same as all “users.” It does not incorporate u or g. Also, remember “o” does NOT stand for “owner.”

The second part of the statement, [The action to be carried out], will be either a “+” or “-” . “+” means you are adding these permissions, while “-” means you are removing them.

The third part of the statement are the permissions that are being changed. As from above they can be either read (“r”), written to (“w”) or executed (“x”).

Putting this all together in an example, say I would want to add a permission for others to write to a file, I would type this in at the command line:

chmod o+r [file to be changed]

Or to remove the permission for the group to execute a file:

chmod g-x [file to be changed]

I can add multiple permissions onto one change order. For instance, say I want to add read and execute permissions for the chief user of the file:

chmod u+rx [file to be changed]

For lovers of numeric abstraction and/or being closer to the metal, there is also a way to change permissions using numbers, I’ll get to that approach (the octal approach) later, in a separate entry. Maybe. If I need to, In the mean time, read about it in the manual page.

Whil I won’t delve into the details, I did want to point out one option, for recursion. This is the -R flag:

chmod -R u+x * [file to be changed]

This above command grants execute permission for all the file, not only in the working directory, but any subdirectories under it (Also, wildcards (*) do work with chmod, but be very sure about what you are changing before you hit that return key).

chmod never changes the values of symbolic links. Those permissions are the same as the file the link is connecting to. Symbolic links is another topic

This post just covers the mechanics, and the basic ones at that. Of course, there are a lot of implications that need to be articulated. Getting user permissions right is a matter of balancing security and ease of use: Granting permissions on an Internet-connected for everyone will ensure your system will be hacked. But keeping them too tight will cause the user aggravation and may hinder programs from working. I’ll explore these topics in future posts.

Taken from various tutorials, Dartmouth Tutorial, and Unix in a Nutshell

–Joab Jackson

And now, a word from our sponsor:





Unix: Removing outside Root access from Ubuntu

Saturday, March 28th, 2009

Every Unix box has a root account, or an account that has absolute control over the machine, its files and controls.

From all accounts, admins should use this account sparingly, only for cases where cross-system control is needed. You can make big mistakes (i.e. wipe out the system with a badly-worded command) from root. If you have work to do that can be done from a user account, use that instead.

Ubuntu has taken this precaution to the next level. When you install Ubuntu, it disables the root account. If you want to do root commands, you issue them from your account through the “sudo” command. basically sudo allows you to issue commands from another user’s account (assuming you have the password).

The idea behind this is that not only will it limit the mistakes you may make, but also reduce the attack footprint of your server. A cracker, trying to get in via SSH, doesn’t even get the option to guess the password to the root account to gain entry, because root can’t log in from SSH at all.

Now, like many old Linux codgers, as soon as I set up Ubuntu, I enabled the root account, mainly because filling in a password every time I wanted to do something in root was a pain. But I just learned that sudo actually has an option (sudo -i) that will allow you to work within a shell of a user account entirely–this means you evoke sudo once and then every thing you do from the command line is done from the account you’ve sudo’d in from, such as root. which is pretty neat, and eliminates the need to be able to access root from the outside (i.e. via SSH).

But if you already enabled root on your Ubuntu, how do you un-enable it? Simple, from the root account, use the psswd command to “lock” the account, i.e. make it inaccessible from outside users. “passwd -l root”

–Joab Jackson





Unix: Removing directory access from Web sites

Wednesday, March 25th, 2009

I learned this from a SANS security class: Don’t expose directory listings for public folders on your Web site. You know, if you type something like “http://www.misc.com/Flounder/” and by typing the end “/” you can get the contents of the directory–including subdirectories. Not good to reveal information you don’t want out, such as non-public directories.

The easiest way to combat this is to simply put an index.html in each directory that is being exposed. It can be an empty page. That way when someone does some path guessing, they are met with this blank page.

Here’s a simple all-black page I used:

<html>
<head>
<title>The Void
<Style type=”text/css”>
body {background-color: #000000}

</head>
<body>
<pre>

</pre>
<center>
<a href=http://www.joabj.com>Home

</center>
</body>
</html>

--Joab Jackson