Tuesday Nov 27, 2007

Trying out mirrored zfs root on Indiana

I've been playing around with project Indiana, and the new installer and packaging system, and they are really nice.

When you install it turns the root disk into a zpool called zpl_slim, but it doesn't let you select two disks and mirror the zpool. Luckily you can fix this once the installation is done. When the system has booted, you can use the zpool attach command:

# zpool attach zpl_slim c7d0s0 c8d0s0
# zpool status
  pool: zpl_slim
 state: ONLINE
 scrub: resilver in progress, 11.75% done, 0h3m to go
config:

        NAME        STATE     READ WRITE CKSUM
        zpl_slim    ONLINE       0     0     0
          mirror    ONLINE       0     0     0
            c7d0s0  ONLINE       0     0     0
            c8d0s0  ONLINE       0     0     0

errors: No known data errors

Friday Aug 31, 2007

Using ZFS ACLs to restrict what a user can do

On some systems where we are really paranoid, we restrict who can execute most setuid and setgid binaries just in case of a zero day exploit. I.e. we only let the administrators can run those commands.

Previously if you wanted to create this kind of restriction, you had to first chmod 4750 the files, and then grant all but the user(s) you wanted to restrict to a group and chgrp the binaries. This was very messy, and you could not have two different sets of restrictions.

Note: if you change file owner, group or permissions for files in a package, you must use installf to update the software installation database.

# chmod 4750 /usr/bin/su
# chgrp sysadmin /usr/bin/su
# installf SUNWcsu /usr/bin/su 4750 root sysadmin

Then came UFS ACLs. It allowed you to add multiple ACLs to the same file, so now you could have multiple sets of files with execute restrictions, but you still had to chmod 4750 all involved files.

Now that we have ZFS it is possible to use the ZFS ACLs to revoke permissions, so if the user danny should not be able to execute /usr/bin/su you can just add an ACL to remove the execute permission for that user.

# chmod A+user:danny:execute:deny /usr/bin/su

Now when danny tries to execute su it'll look like this:

$ ls -l /usr/bin/su
-r-sr-xr-x+  1 root     sys        34624 Feb 26  2007 /usr/bin/su
$ su -
bash: su: Permission denied

As with UFS ACLs the way to spot that a file has an ACL is the + sign at the end of the permissions when you execute ls -l. If you want to see the full ACL use this

$ ls -v /usr/bin/su
-r-sr-xr-x+  1 root     sys        34624 Feb 26  2007 /usr/bin/su
     0:user:danny:execute:deny
     1:owner@:write_data/append_data:deny
     2:owner@:read_data/write_xattr/execute/write_attributes/write_acl
         /write_owner:allow
     3:group@:write_data/append_data:deny
     4:group@:read_data/execute:allow
     5:everyone@:write_data/append_data/write_xattr/write_attributes
         /write_acl/write_owner:deny
     6:everyone@:read_data/read_xattr/execute/read_attributes/read_acl
         /synchronize:allow

[Technorati Tags: ]

Thursday Aug 09, 2007

ZFS the perfect file system for audit trails

Those of you who have to deal with audit trails from busy systems know that they can get really big, and when you need to store them for a couple of years they consume a considerable amount of disk.

To minimize the disk usage that you can compress the audit trails, and it works really well (I've adjusted the output to right-align the size):

root@warlord# ls -l
total 19447638
-rw-r--r--   1 root     other    1353214369 Aug  9 09:27 20070728065900.20070730163539.warlord
-rw-------   1 root     other      62209268 Aug  7 08:25 20070728065900.20070730163539.warlord.gz
-rw-r--r--   1 root     other    1965073391 Aug  7 09:35 20070728065900.20070730163539.warlord.txt
-rw-r--r--   1 root     other      71460194 Aug  7 09:35 20070728065900.20070730163539.warlord.txt.gz

As you can see the compression ratio is really good (over 90%), but one problem still remains: if you need to work with the files you have to uncompress them before you can run your scripts to go an find who edited /etc/passwd. Uncompressing one file doesn't take that long, but when you don't know exactly in which file the audit records you are looking for are, things start to take time.

Enter ZFS: with on-the-fly disk compression it is the perfect file system to store audit trails. First of all you have to enable compression:

root@warlord# zfs set compression on pool/audit

That only makes future writes compressed, so the files you already have needs to be rewritten to be compressed. After having done that it is time to look at the compression ratio:

root@warlord# ls -l
total 19447638
-rw-r--r--   1 root     other    1353214369 Aug  9 09:27 20070728065900.20070730163539.warlord
-rw-r--r--   1 root     other    1965073391 Aug  7 09:35 20070728065900.20070730163539.warlord.txt

Wait a minute! That didn't compress anything, or did it? ls -l shows the size of the uncompressed file, so you have to use du to see the compressed size:

root@warlord# du -k
554067  20070728065900.20070730163539.warlord
732399  20070728065900.20070730163539.warlord.txt

Much better! (Note that it displays the size in kilo bytes while ls -l displays it in bytes) But it still is not as good as when I ran gzip on them. Why? ZFS uses the LZJB compression algorithm which isn't as space effecient as the gzip algorithm, but it is much faster. If I had been running Nevada I could have used:

root@warlord# zfs set compression gzip pool/audit

And have gotten the same compression ratio as when I "hand compress" my audit trails. This thanks to Adam who integrated gzip support in ZFS in build 62 of Nevada.

[Technorati Tags: ]

About

martin

Search

Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today