Ubuntu Feisty is out!

19 04 2007

Just a minute ago:

http://releases.ubuntu.com/7.04/
http://mirrors.cat.pdx.edu/ubuntu-iso/feisty/

EDIT: Those where the correct Feisty ISOs, http://www.ubuntu.com/ links to them with the same md5sums

EDIT: Its still up in the air if this is actually the final release or not.

The iso that is up now is in the directory where you would expect to find a final release and it is being mirrored to other servers.

The md5sums are the same from the 15th livecd and the timestamp is also the 15th (except for the torrent which is the 19th but the tracker is down), this would happen if there weren’t any changes from the 15th build because it worked fine.

Ops in the #ubuntu channels keep telling everyone that its not ‘released’ yet, saying wait for the official announcement, but if they mean that it hasn’t been ‘official decreed’ from the powers above so its technically not released or if they mean that the file in the iso directory isn’t the correct version. It’s also possible that the file is probably the final, but there is a slight chance of it being changed right at the last minute.

I can’t really see why its in the folder if its not the final release unless there is a mirror system the can handle binary differences between the isos, so that putting up an out of date version will mean that the mirror only have to download the small difference allowing them to get it quicker.

So it may or may not be the final release, I’ve got it downloading, I’ll check the md5sums when its actually released to see if it changes or not.

Advertisements




Linux/UNIX Permissions

17 04 2007

I’m writing this because people sometimes seems to have trouble understanding the permissions under unix and get confused with setting permissions like 777 or 555.

Permissions
Basically every file and directory has a username and group associated with it. It then has 3 sets of permissions for owner and group and other.

root user and the owner of the file have full control as to what permissions can be set, owner can for instance can remove roots permissions to read it but this can be overridden by root. But it is important to remember that by default root would be blocked for accessing the file until it is overridden so things like auto cleaning scripts to remove files from a directory could be bypassed if they aren’t coded to correctly ignore permissions, this can be an advantage if you want to allow users to be able do so.

The 3 sets of permissions each consist of 3 settings, Read, Write and eXecute which being binary are either on or off.

For files what each of these does is fairly obvious:

  • Read allows you to read data from the file
  • Write allows to the modify the file (including deleting it)
  • execute chooses weather you can run the file, the execute bit isn’t secure as it would be possible to use another program to execute the file regardless of whether the execute bit is set such as using sh to call a shell script directly so you would need a fairly heavily locked down system until you can be %100 sure that a file with the execute bit disable won’t be executable by someone who is going out of their way to do so. You also need to be able to read a file in order to execute it.
  • Extra info: Execute can also be set to be S instead of x, this allows the executed program to be run with the permissions of the owner of the program, rather than the permissions of the user running it. This can be a very bit security rist.
  • Directories are a little bit different:

  • the execute bit decides weather you can enter the directory so you can’t ‘cd /directory’ into the directory but you can ‘ls /directoy’.
  • Read is used to determine if you can list the contents of the directory so you can block the ability to use ls to list the contents but still allow a user to enter the directory with cd by allowing execute, is it is possible to create a file in a directory that can be accessed by specifying the full path name without being able to browse the directory itself
  • Write allows you to create files in a directory, and also delete/rename the directory itself and files inside the directory (regardless of owner). You can write to a file without having read access
  • Extra into: Write access leads to a problem, user can delete/rename the directory itself or files that aren’t theirs, if you want a directory that users can create files in but you want to stop them from deleting it, such as /tmp this is solved by having an extra bit called the sticky bit (+t), t only shows up for the ‘other’ user since the owner and root are expected to beable to delete their own directory. If the /tmp is missing the sticky bit then a user can cause havock with the system by deleting the tmp directory that is require for a lot of programs. Files can also have the sticky bit but it is ignored nowdays, it was designed to allow the files to ‘stick’ in memory.

    STICKY FILES
    On older Unix systems, the sticky bit caused executable files to be
    hoarded in swap space. This feature is not useful on modern VM sys‐
    tems, and the Linux kernel ignores the sticky bit on files. Other ker‐
    nels may use the sticky bit on files for system-defined purposes. On
    some systems, only the superuser can set the sticky bit on files.

    STICKY DIRECTORIES
    When the sticky bit is set on a directory, files in that directory may
    be unlinked or renamed only by the directory owner as well as by root
    or the file owner. Without the sticky bit, anyone able to write to the
    directory can delete or rename files. The sticky bit is commonly found
    on directories, such as /tmp, that are world-writable.

  • Permissions as shown in a ls:
    U G O ref user grp size date time name
    drwxrwxrwt 13 root root 16K 2007-04-17 23:09 tmp

    The ‘d’ stands for directory, for normal files this will be a ‘-‘. Next we have the 3 permissions for owning user (root) ‘rwx’, then the 3 for group (root) ‘rwx’ and then the 3 for other users ‘rwt’. So root and owner have full permissions (in this case the owner is also root) but all other users have almost full permissions but cannot modify the directory itself.

    Then there is a counter, this isn’t important to under stand by it counts how many times that file/directory is referenced when it is 0 the file system will consider that space to be free space and it will be used for any new files created, for normal files this is normally 1, unless that file has been hard linked. for directors this changes depending on the number of subdirectories it contains, since each sub directory has a link back to the parent directory in the form of ‘..’, a directory without sub directories has 2, one for the parent directories link and another for the directories link to itself.

    We then have the username (root) which is associated with the owner permissions and then the group (also root) associated with the groups permissions. Then the time and date.

    Groups
    Users have a primary group but can belong to multiple supplemental groups. This is defined in the /etc/group file. This was its possible to have a file that one user can modify as their own, people in the same group as the file can read but not modify and everyone else is completely blocked. You can also use ‘usermod’ to change which groups a user belongs in. You can see what groups you are in with ‘id’

    For example:
    usermod -ag newgroup username
    The -a tells usermod to append the groups, without it any groups the user is in would be removed if they weren’t specified. -g is for secondary groups, normally these are all you only need to change.

    Mount points
    It is a good idea to have no permissions enabled for unmounted mount points such as /mnt/cdrom, you can then set another set of permissions for when it is mounted which will automatically be applied each time that file system is mounted. If you want regular uses to be able to mount something that is set in /etc/fstab not on the mount point permissions. Doing this will give users a permission denied error if they try to access an unmounted directory, rather than just getting an empty directory.

    letter mode vs octal letter permissions
    Often you will see chmod commands with number such as ‘chmod 750 /tmp/somefile’ these are permissions in octal mode (octal because there are 8 choices, 0-7), there is one number is for user,group and other. The numbers are a combination of the different permissions, each permission type is assigned a value, Execute is 1, write is 2 and read is 4, these numbers can them be added together to get a permission, such as 5 which is read and execute, or 7 which is full permissions. Sometimes there is a 4th number than is for the extra bits such as sticky and sudo. ‘man chmod’ for more information.

    If you don’t like the number system you can use the easier to remember letter system.
    Such as ‘chmod ugo+rwx’ which gives user, group and other full permissions.

    Setting permissions en mass
    You might want to set all files in a directory to one set of permissions such as 644, to allow user read and write, but everyone else read only. This can be done with ‘chmod -R 644 /directory’ but it has a problem, if you have sub directories and set these permissions the sub directories users will not be able to enter them because they need execute access. You can fix this with the command ‘chmod -R ugo+X /directory’, the capital X tells chmod to only apply executable bit on directories.





    Quick simple encrypted loopback filesystem

    16 04 2007

    UPDATE: For the extremely paranoid cryptoloop has a minor known vulnerability, it is possible to detect the presence of a specially created file in the file system, it shouldn’t cause a problem for most people. Wikipedia explains it here. If it is a concern for you then you might want something a bit more extreme. Cryptoloop has been superseded by dm-crypt, there is also truecrypt which can do 3 encryption algorithms at once and also hide your real encrypted fs under a dummy one. I’ll probably write up some more about them later.

    I’m doing the following under Debian Etch but Ubuntu Feisty should work exactly the same, other Linux distros might need the correct cryptoloop & aes encryption modules for the kernel and ‘/dev/loop0’ might change to ‘/dev/loop/0’, The kernel modules required for encryption are included in linux-image for both Debian and Ubuntu. As of Etch Debian also has fairly good support for encryption to be setup during the installation but thats not the goal of this article.

    Firstly you need to create a loop back image for your file system to use, the easiest way to do this is to output random data into a file, this will take a while for larger sizes, alternativly you could use /dev/zero but this could theoretically be less secure.
    dd if=/dev/urandom of=encrypted.img bs=1M count=100

    That will make a 100Mb loop back image, change the numbers to suit your desired size.

    Next we want to bind our image to a loopback device:
    losetup -e aes /dev/loop0 encrypted.img
    At this point you will be asked for a password, type it in. I recommend you use a longer pass phrase rather than a password, like an entire sentence with mixed case and numbers/symbols. When I was following some older how-tos i was getting an “ioctl: LOOP_SET_STATUS: Invalid argument”, that was because they had “-e AES256” rather than “-e aes”, with newer versions if you want to manually specify a keylength you use the -k flag although the default should be fine.

    Another common error is “ioctl: LOOP_SET_STATUS: Invalid argument” this is generally the result of not loading the correct modules, “modprobe aes loop cryptoloop” (actually cryptoloop will probally load everything required).

    Now we want to make a file system on it, works just like making one on a hard drive except we use the loopback device, most other howto’s I’ve seen on the subject seem to use ext2, on ext3 it is somewhat harder to recover deleted files (which could be a good thing for encrypted data) and you get journals that can help reduce/detect data loss. [EDIT: Now there is ext4 with things like extents which reduce fragmentation (although if your on a loopback device the loopback image will probably itself have some fragmentation too), journal checksumming, much faster fsck and other goodies (also btrfs but as of now it’s experimental).] Change ext4 to ext3, ext2 or btrfs if you want:
    mkfs.ext4 /dev/loop0

    Now we unbind the image from the interface:
    losetup -d /dev/loop0

    Now for automated mouting we want to make a mount point and edit the fstab:
    mkdir /mnt/encrypted

    To make sure that noone can access the mount point when the filesystem isn’t mounted, we need to set the correct permissions:
    chown 700 /mnt/encrypted

    The /etc/fstab entry should look like the following:
    /directory/with/image/encrypted.img /mnt/encrypted ext3 defaults,noauto,loop=/dev/loop0,encryption=aes 0 0

    Now try and mount it:
    mount /mnt/encrypted

    This should ask you for your password, if you get an error “mount: wrong fs type, bad option, bad superblock on /dev/loop/0,” you probably mistyped your password, otherwise you broke something.

    Make sure the permissions on the folder for its mounted state are correct, the following will only allow the user with you username to browse the directory (and root):
    chown -R username:username /mnt/encrypted
    chmod 770 /mnt/encrypted

    Remember that an encrypted system isn’t %100 secure, files can be cached in the swap drive, it is possible to encrypt swap space but you will loose some performance (Now days it might be better to just ensure you have plenty of ram and disable swap). Some programs will also cache information from the encrypted folder, such as file managers that make thumbnails for text/images/videos. It is possible to encrypt an entire installation, but generally there ins’t much point since files aren’t going to be saved in places like /usr/ and you will loose a lot of performance. It is also possible to use a encryption key file, rather than a password, this allows you to keep it on a USB drive but its possible the USB drive could be stolen too, or sized by the goverment tracking your MP3 downloading :p I would also recommend backing up the usb key in case you loose the key but not a laptop.

    If you want to increase the size of the filesystem later, firstly you need to add extra blocks to the file, to add 200Mb to the file:
    dd if=/dev/urandom bs=1M count=200 >> encrypted.img

    You can then resize the partition while it is mounted (its probably possible and best to do it when it isn’t but /dev/loop0 with losetup wasn’t doing it for me and increasing the size of an ext3 partition seems safeish and wasn’t throwing any warnings about it needing to be done offline):
    mount /mnt/encrypted
    resize2fs /dev/loop0