29.1 A Review of User-Level Security Settings

     

29.1 A Review of User -Level Security Settings

We start with the basics: file and directory permissions. Commonly, I find in the UNIX arena that administrators often have misconceived ideas about what file and directory permissions actually mean. Let's put those misconceptions to rest once and for all.

29.1.1 File and directory permissions

I am not going to spend lots of time going through what read permissions give you in respect of files or directories. What I am going to do is pose some questions. If you can't answer these questions, then I would suggest that you study your CSA materials a little closer:

Q1.

Why do we use the shell built-in function umask in favor of the UNIX command /bin/umask to affect the file creation mode of files in our shell?

Q2.

What will be the file permissions if I create a file via the shell when my umask = a-rwx,u=rwx,g=rx ?

Q3.

What file and directory permissions do you need to delete a file?

Q4.

Can you provide permissions only to append information to a file?

Q5.

Why are the permissions on a hard link always the same as the permissions on the original file?

Q6.

Why is it that users can change their passwords with the passwd command when the /etc/passwd file is read-only?

Q7.

What are two problems with creating an SUID-to-root shell script?

Q8.

Why do SUID-to-root programs not always give you full access to system features that you would expect?

Q9.

A directory has the SGID bit set and is owned by root:sys . A user fred:quarry creates a file in that directory. What will be the group ownership of the file created by the user fred:quarry ?

Q10.

Why is the sticky-bit so called and why is it less relevant these days?

Q11.

How do we allow one user to create files in a world- writeable directory but disallow other users from deleting those files?

I don't think it unreasonable for a CSA to know the answers to these questions. If you feel the need, the answers are at the end of this chapter, but no peeking .

A topic we discuss here is Access Control Lists (ACL). ACLs are supported on both HFS and VxFS (recently) filesystems. They allow a system that is converted to an HP-UX Trusted System to conform to the Orange Book classification of C2 mandatory access controls (see later). With ACLs we can give individual users their own individual permissions for files and directories. In this way, we can customize user access to individual user's requirements, whereas with traditional UNIX permissions, we are stuck with the three- tier structure of user, group, and other.

29.1.1.1 VXFS ACCESS CONTROL LISTS

As of VxFS version 3.3 (layout version 4) we can apply ACLs to VxFS files and directories. To check your layout version, use the fstyp -v command:

 

 root@hpeos004[]  fstyp -v /dev/vg00/lvol3  vxfs  version: 4  f_bsize: 8192 f_frsize: 1024 f_blocks: 1302528 f_bfree: 313226 f_bavail: 313226 f_files: 9216 f_ffree: 2139030336 f_favail: 2139030336 f_fsid: 1073741827 f_basetype: vxfs f_namemax: 254 f_magic: a501fcf5 f_featurebits: 0 f_flag: 0 f_fsindex: 7 f_size: 1302528 root@hpeos004[] 

If you have an earlier version of VxFS, then you can download VxFS 3.3 free of charge from http://software.hp.com. It is available for HP-UX 10.20, 11.0, and 11i. To upgrade a VxFS filesystem to support ACLs, we can use the vxupgrade command. The default ACL is known as the base ACL. We can apply up to 13 additional ACL entries per file and directory because VxFS ACLs are stored in the 44-byte attribute area of a VXFS inode. The commands to list and modify VxFS ACLs are getacl and setacl . Here, we can see a list of ACL entries for the /etc/passwd file:

 

 root@hpeos004[]  getacl /etc/passwd  # file: /etc/passwd # owner: root # group: sys user::r-- group::r-- class:r-- other:r-- root@hpeos004[] 

I am going to add additional ACLs for this file. I know this is not the best file to choose, but it's only for demonstration purposes. Here, I am allowing a user fred to write to this file, and barney read and write access:

 

 root@hpeos004[]  setacl -m 'user:fred:w,user:barney:rw' /etc/passwd  root@hpeos004[]  getacl /etc/passwd  # file: /etc/passwd # owner: root # group: sys user::r-- user:barney:rw- user:fred:-w- group::r-- class:rw- other:r-- root@hpeos004[] 

I can also add group level ACLs. Here the group quarry is given read and execute permission:

 

 root@hpeos004[]  setacl -m 'group:quarry:rx' /etc/passwd  root@hpeos004[]  getacl /etc/passwd  # file: /etc/passwd # owner: root # group: sys user::r-- user:fred:-w- user:barney:rw- group::r-- group:quarry:r-x class:rwx other:r-- root@hpeos004[] 

You might have noticed the class group entry. This is a catchall entry that signifies the maximum permissions allowed for the file or directory, depending on individual user/group level access. Whenever we add, delete, or modify an ACL entry, the class entry is recalculated to reflect the new maximum permissible combination of permissions. It can be used to great effect when we want to temporarily deny access to all additional ACL entries. In this example, I am using the “n option, which means that we do not want to recalculate the group class ; this makes sense because we are modifying the class directly:

 

 root@hpeos004[]  setacl -nm 'class:---' /etc/passwd  root@hpeos004[]  getacl /etc/passwd  # file: /etc/passwd # owner: root # group: sys user::r-- user:fred:-w-   #effective:--- user:barney:rw- #effective:--- group::r--      #effective:--- group:quarry:r-x        #effective:--- class:--- other:r-- root@hpeos004[] 

We can set this back to its previous value to reactivate the additional ACL entries:

 

 root@hpeos004[]  setacl -m 'class:rwx' /etc/passwd  root@hpeos004[]  getacl /etc/passwd  # file: /etc/passwd # owner: root # group: sys user::r-- user:fred:-w- user:barney:rw- group::r-- group:quarry:r-x class:rwx other:r-- root@hpeos004[] 

One thing to remember about ACLs is that they are an additional security attribute on a per-file and per-directory basis. As such, some traditional UNIX utilities will exhibit slightly strange behavior when interacting with ACLs; look at the output from a long listing:

 

 root@hpeos004[]  ll /etc/passwd  -r--rwxr--+  1 root       sys            862 Oct  4 15:07 /etc/passwd root@hpeos004[] 

Notice the plus (+) symbol after the permission bits? As long as you remember that you have applied ACLs, this kind of output will simply remind you that ACLs have been applied. Look at the permissions displayed by a long listing; by adding additional ACL entries, a long listing will display an amalgamation of the permissions for all additional ACL entries. Another command with slightly different behavior is chmod . If we change the mode permissions on a file with ACLs applied, chmod will affect the group class setting.

 

 root@hpeos004[]  chmod 444 /etc/passwd  root@hpeos004[]  ll /etc/passwd  -r--r--r--+  1 root       sys            862 Oct  4 15:07 /etc/passwd root@hpeos004[]  getacl /etc/passwd  # file: /etc/passwd # owner: root # group: sys user::r-- user:fred:-w-   #effective:--- user:barney:rw- #effective:r-- group::r-- group:quarry:r-x        #effective:r-- class:r-- other:r-- root@hpeos004[] 

We would need to reapply the setacl command(s) afterward to reset the group class back to its former setting.

Another aspect of ACLs is their relationship with standard UNIX backup utilities. tar , cpio , and pax do not know what an ACL is and will print out a warning message to the effect that the ACL for the file is not backed up.

 

 root@hpeos004[]  pax -w -f /tmp/pax.out /etc  pax: /etc/passwd : Optional ACL entries are not backed up. root@hpeos004[] 

This can have an effect on your disaster recovery procedures such as make_net_recovery , which use pax/tar as a backup interface. You may have to create an ACL-apply file where all ACL entries are listed in a file that can be applied with the setacl “m “f <filename> command once a machine has been Ignite-UX recovered.

 

 root@hpeos003[]  getacl /etc/passwd  # file: /etc/passwd # owner: root # group: sys user::r-- user:barney:rw- user:fred:-w- group::r-- group:quarry:r-x class:rwx other:r-- root@hpeos003[] root@hpeos003[]  mkdir ~root/ACL  root@hpeos003[]  getacl /etc/passwd > ~root/ACL/passwd.acl  root@hpeos003[]  cat ~root/ACL/passwd.acl  # file: /etc/passwd # owner: root # group: sys user::r-- user:barney:rw- user:fred:-w- group::r-- group:quarry:r-x class:rwx other:r-- root@hpeos003[] root@hpeos003[]  setacl -d 'user:fred,user:barney,group:quarry' /etc/passwd  root@hpeos003[]  getacl /etc/passwd  # file: /etc/passwd # owner: root # group: sys user::r-- group::r-- class:r-- other:r-- root@hpeos003[] root@hpeos003[]  setacl -f ~root/ACL/passwd.acl /etc/passwd  root@hpeos003[]  getacl /etc/passwd  # file: /etc/passwd # owner: root # group: sys user::r-- user:barney:rw- user:fred:-w- group::r-- group:quarry:r-x class:rwx other:r-- root@hpeos003[] 

If the ACL-apply file was part of the Recovery Archive, you could implement the routine as a post_configure_cmd !

29.1.1.2 HFS ACCESS CONTROL LISTS

HFS Access Control Lists give us the same benefits as VxFS ACLs. They are implemented slightly differently in the filesystem; they use an additional inode called the continuation inode to store the ACL entries. Like VxFS ACLs, we can have up to 13 additional ACL entries per file or directory. If you are tuning your HFS filesystem such that you are restricting the number of inodes created, if you have additional ACL entries for every file, you will effectively have half as many inodes available. HFS ACLs also cause problems to backup commands like tar , cpio , and pax and hence similar problems surrounding Ignite-UX recoveries . We also see similar behavior from a long listing. One difference is the commands we use to list and set ACL entries, lsacl and chacl in this case:

 

 root@hpeos004[]  lsacl -l /stand/vmunix  /stand/vmunix: rwx root.% r-x %.sys r-x %.% root@hpeos004[] 

In this case, the percent ( % ) symbol indicates a wildcard. So an entry of the form fred.% would mean the user fred in any group . Here, I am giving fred write access, barney read and write access, and the group quarry read and execute access to the /stand/vmunix file (no, it's not a good file to choose, but it's only a demonstration):

 

 root@hpeos004[]  chacl 'fred.%=w,barney.%=rw,%.quarry=rx' /stand/vmunix  root@hpeos004[]  lsacl -l /stand/vmunix  /stand/vmunix: rwx root.% -w- fred.% rw- barney.% r-x %.sys r-x %.quarry r-x %.% root@hpeos004[] 

An interesting feature of HFS ACLs is their behavior in relation to the chmod command. With VxFS ACLs, we saw that chmod affected only the class specification. With HFS ACLs, using chmod will delete the additional ACL entries:

 

 root@hpeos004[]  ll /stand/vmunix  -rwxr-xr-x+  1 root       sys        25932192 Sep 20 10:32 /stand/vmunix root@hpeos004[]  chmod 755 /stand/vmunix  root@hpeos004[]  ll /stand/vmunix  -rwxr-xr-x   1 root       sys        25932192 Sep 20 10:32 /stand/vmunix root@hpeos004[]  lsacl -l /stand/vmunix  /stand/vmunix: rwx root.% r-x %.sys r-x %.% root@hpeos004[] 

There is the “A option to chmod that preserves additional ACL entries:

 

 root@hpeos004[]  chacl 'fred.%=w,barney.%=rw,%.quarry=rx' /stand/vmunix  root@hpeos004[]  lsacl -l /stand/vmunix  /stand/vmunix: rwx root.% -w- fred.% rw- barney.% r-x %.sys r-x %.quarry r-x %.% root@hpeos004[]  chmod -A 755 /stand/vmunix  root@hpeos004[]  ll /stand/vmunix  -rwxr-xr-x+  1 root       sys        25932192 Sep 20 10:32 /stand/vmunix root@hpeos004[]  lsacl -l /stand/vmunix  /stand/vmunix: rwx root.% -w- fred.% rw- barney.% r-x %.sys r-x %.quarry r-x %.% root@hpeos004[] 

You might want to think about setting up a system-wide alias for chmod to alias to chmod “A if you use HFS ACLs extensively.



HP-UX CSE(c) Official Study Guide and Desk Reference
HP-UX CSE(c) Official Study Guide and Desk Reference
ISBN: N/A
EAN: N/A
Year: 2006
Pages: 434

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net