Umask
===========
- Configuring Default File / Directory Permissions
When a user creates a file, how does the system determine that file's initial permissions?
This is done based on the user's umask value.
The umask value specifies which permissions are not to be set.
In Ubuntu, the default umask value for a normal user is 002, while the default for root is 022.
You can find out the current umask value (or set it) using the umask command.
If (as a normal user) you run the command:
umask
You'll see something like 0002 displayed, however octal numbers are preceded by a 0 (in the same way hex would be preceded by 0x), so the umask value itself is actually 002.
This value is an octal (base 8, digits 0-7) value which is subtracted from a base value of 777 for directories, or subtracted from a base value of 666 for files.
A umask of 002 basically means don't remove any permissions from the base value for "user" or "group", but "other" is not allowed write permission (write permission is octal 2, or binary 010 meaning -w-).
So if we create a new file:
touch newfile.txt
The file permissions for this new file will be 666-002 = 664, i.e. rw-rw-r-- (readable and writeable by user and group, but only readable by everyone else).
Similarly, if we create a new directory:
mkdir newDir
The file permissions for the directory newDir will be 777-002 = 775, i.e. drwxrwxr-x (readable, writeable, executable by user and group, but only readable and executable by everyone else).
If you wish to set the umask value to something else, simply use umask command like so:
umask newvalue
where "newvalue" is an octal number representing which permissions you do not want to be set when files are created.
http://www.cyberciti.biz/tips/understanding-linux-unix-umask-value-usage.html
---------------------------------------------------------------------------------------------------------------
ACL in Linux
=============
Read=4
write=2
execute=1
ACL IN LINUX
root@testvm:~# mount | grep root
/dev/mapper/workstation-root on / type ext4 (rw,errors=remount-ro)
tune2fs -l /dev/mapper/workstation-root
tune2fs 1.42 (29-Nov-2011)
Filesystem volume name:
Last mounted on: /
Filesystem UUID: f558402c-a418-4892-87e2-071c1a85898c
Filesystem magic number: 0xEF53
Filesystem revision #: 1 (dynamic)
Filesystem features: has_journal ext_attr resize_inode dir_index filetype needs_recovery extent flex_bg sparse_super large_file huge_file uninit_bg dir_nlink extra_isize
Filesystem flags: signed_directory_hash
Default mount options: user_xattr acl
FIle system supports ACL, update it in fstab
root@testvm:/var/tmp# ls -la | grep appdir
drwxrwxr-x 2 root appgroup 4096 May 27 10:45 appdir
To add these permissions we will use the setfacl command
root@testvm:/var/tmp# setfacl -m g:testusers:r appdir/
getfacl appdir/
# file: appdir/
# owner: root
# group: appgroup
user::rwx
group::rwx
group:testusers:r--
mask::rwx
other::r-x
Identifying files/directories that have ACL's
root@testvm:/var/tmp# ls -la | grep appdir
drwxrwxr-x+ 2 root appgroup 4096 May 27 10:45 appdir
As you can see there is now a + at the end of the directories permissions.
Removing all acl entries from a file or directory
setfacl -b appdir/
Set testusers to have read access to all files in the appdir directory
setfacl -m g:testusers:r appdir/
Set the changes recursively
setfacl -Rm g:testusers:r appdir/
Set the same acl's on all newly created files automatically
setfacl -dm g:testusers:r appdir/
root@testvm:/var/tmp# touch appdir/file1
root@testvm:/var/tmp# mkdir appdir/dir1
root@testvm:/var/tmp# getfacl appdir/*
# file: appdir/appuser1
# owner: appuser1
# group: appgroup
user::rwx
group::r-x
group:testusers:r--
mask::r-x
other::r-x
# file: appdir/appuser2
# owner: appuser2
# group: appgroup
user::rwx
group::r-x
group:testusers:r--
mask::r-x
other::r-x
# file: appdir/dir1
# owner: root
# group: root
user::rwx
group::rwx
group:testusers:r-- mask::rwx
other::r-x
default:user::rwx
default:group::rwx
default:group:testusers:r-- default:mask::rwx
default:other::r-x
# file: appdir/file1
# owner: root
# group: root
user::rw-
group::rwx #effective:rw-
group:testusers:r-- mask::rw-
other::r--
Remove the acl for testuser1 on appuser1 directory
setfacl -x u:testuser1 appdir/
-----------------------------------------------------------------------------------------------------------------------
SELinux
========
sestatus
SELinux status: enabled
SELinuxfs mount: /selinux
ps axZ | grep httpd
system_u:system_r:httpd_t 3234 ? Ss 0:00 /usr/sbin/httpd
Finally, let's look at the SELinux security context of a file in our home directory:
$ ls -Z /home/username/myfile.txt
-rw-r--r-- username username user_u:object_r:user_home_t /home/username/myfile.txt
The 'chcon' command may be used to change SELinux security context of a file or files/directories
mkdir /html
# touch /html/index.html
# ls -Z /html/index.html
-rw-r--r-- root root user_u:object_r:default_t /html/index.html
# ls -Z | grep html
drwxr-xr-x root root user_u:object_r:default_t html
chcon -v --type=httpd_sys_content_t /html
context of /html changed to user_u:object_r:httpd_sys_content_t
# chcon -v --type=httpd_sys_content_t /html/index.html
context of /html/index.html changed to user_u:object_r:httpd_sys_content_t
# ls -Z /html/index.html
-rw-r--r-- root root user_u:object_r:httpd_sys_content_t /html/index.html
# ls -Z | grep html
drwxr-xr-x root root user_u:object_r:httpd_sys_content_t html
Equally we could have set both in one go using the -R recursive switch:
# chcon -Rv --type=httpd_sys_content_t /html
To make the security context changes permanent, even through a complete filesystem relabel, we can use the SELinux Management Tool or the 'semanage' command from the command line:
semanage fcontext -a -t httpd_sys_content_t "/html(/.*)?"
Restore Default Security Contexts
restorecon -Rv /var/www/html
Allowing Access to a Port
semanage port -a -t http_port_t -p tcp 81
semanage port -l
-----------------------------------------------------------------------------------------------------------------
SETUID SETGUID AND STICKY BIT PERMISSION
--------------------------------------
A lower case s is used where the execute bit is on, and an upper case S where the execute bit is not set.
SUID (Set User ID) => When a SUID bit is set on a command then that command always executes with the User ID of its own user owner (who created it) instead of the user who is executing it.
EXAMPLE: The binary of passwd command has SUID permission set on it, that is why, when unpriviledged users execute this command, it always executes with the UID of "root" and changes their password in /etc/shadow (which is only readable or writable by root).
To set SUID on a program, run:
[kh@server ~]$ chmod u+s "/path/to/command/binary"
4755, would set the setuid bit (4)
SGID (Set Group ID)(on command binary) => When SGID permission is set on any command, then that command runs with the Group ID of group owner of the command's binary instead of GID of the user who is executing it. To set SGID on a program, run:
[kh@server ~]$ chmod g+s "/path/to/command/binary"
SGID (Set Group ID)(on directories) => When SGID permission is set on a directory, then all the new (future) files created under that directory will have the same group owner as that of the parent directory. Moreover subdirectories (created in future) will also have SGID bit on them. Example: If we set SGID on a directory, for example: on /tmp/test with group owner as "john", now if another user "mike" creates any file in /tmp/test directory then the user owner of this file will be "mike" but group owner will be "john" because of SGID on parent directory. To set SGID on a directory, run:
[kh@server ~]$ chmod g+s /path/to/directory
Sticky Bit => The new files created under the directory having Sticky Bit on it can be only deleted by root or the user who created that file. No other user can delete that file even if they have write permission on the parent directory. EXAMPLE: /tmp directory is having Sticky Bit permission on it, that is why the content under this can be only deleted by root or the user owner of the content/file. To set Sticky Bit on a directory, run:
[kh@server ~]$ chmod o+t /path/to/directory
» 27072 reads
===========
- Configuring Default File / Directory Permissions
When a user creates a file, how does the system determine that file's initial permissions?
This is done based on the user's umask value.
The umask value specifies which permissions are not to be set.
In Ubuntu, the default umask value for a normal user is 002, while the default for root is 022.
You can find out the current umask value (or set it) using the umask command.
If (as a normal user) you run the command:
umask
You'll see something like 0002 displayed, however octal numbers are preceded by a 0 (in the same way hex would be preceded by 0x), so the umask value itself is actually 002.
This value is an octal (base 8, digits 0-7) value which is subtracted from a base value of 777 for directories, or subtracted from a base value of 666 for files.
A umask of 002 basically means don't remove any permissions from the base value for "user" or "group", but "other" is not allowed write permission (write permission is octal 2, or binary 010 meaning -w-).
So if we create a new file:
touch newfile.txt
The file permissions for this new file will be 666-002 = 664, i.e. rw-rw-r-- (readable and writeable by user and group, but only readable by everyone else).
Similarly, if we create a new directory:
mkdir newDir
The file permissions for the directory newDir will be 777-002 = 775, i.e. drwxrwxr-x (readable, writeable, executable by user and group, but only readable and executable by everyone else).
If you wish to set the umask value to something else, simply use umask command like so:
umask newvalue
where "newvalue" is an octal number representing which permissions you do not want to be set when files are created.
http://www.cyberciti.biz/tips/understanding-linux-unix-umask-value-usage.html
---------------------------------------------------------------------------------------------------------------
ACL in Linux
=============
Read=4
write=2
execute=1
ACL IN LINUX
root@testvm:~# mount | grep root
/dev/mapper/workstation-root on / type ext4 (rw,errors=remount-ro)
tune2fs -l /dev/mapper/workstation-root
tune2fs 1.42 (29-Nov-2011)
Filesystem volume name:
Last mounted on: /
Filesystem UUID: f558402c-a418-4892-87e2-071c1a85898c
Filesystem magic number: 0xEF53
Filesystem revision #: 1 (dynamic)
Filesystem features: has_journal ext_attr resize_inode dir_index filetype needs_recovery extent flex_bg sparse_super large_file huge_file uninit_bg dir_nlink extra_isize
Filesystem flags: signed_directory_hash
Default mount options: user_xattr acl
FIle system supports ACL, update it in fstab
root@testvm:/var/tmp# ls -la | grep appdir
drwxrwxr-x 2 root appgroup 4096 May 27 10:45 appdir
To add these permissions we will use the setfacl command
root@testvm:/var/tmp# setfacl -m g:testusers:r appdir/
getfacl appdir/
# file: appdir/
# owner: root
# group: appgroup
user::rwx
group::rwx
group:testusers:r--
mask::rwx
other::r-x
Identifying files/directories that have ACL's
root@testvm:/var/tmp# ls -la | grep appdir
drwxrwxr-x+ 2 root appgroup 4096 May 27 10:45 appdir
As you can see there is now a + at the end of the directories permissions.
Removing all acl entries from a file or directory
setfacl -b appdir/
Set testusers to have read access to all files in the appdir directory
setfacl -m g:testusers:r appdir/
Set the changes recursively
setfacl -Rm g:testusers:r appdir/
Set the same acl's on all newly created files automatically
setfacl -dm g:testusers:r appdir/
root@testvm:/var/tmp# touch appdir/file1
root@testvm:/var/tmp# mkdir appdir/dir1
root@testvm:/var/tmp# getfacl appdir/*
# file: appdir/appuser1
# owner: appuser1
# group: appgroup
user::rwx
group::r-x
group:testusers:r--
mask::r-x
other::r-x
# file: appdir/appuser2
# owner: appuser2
# group: appgroup
user::rwx
group::r-x
group:testusers:r--
mask::r-x
other::r-x
# file: appdir/dir1
# owner: root
# group: root
user::rwx
group::rwx
group:testusers:r-- mask::rwx
other::r-x
default:user::rwx
default:group::rwx
default:group:testusers:r-- default:mask::rwx
default:other::r-x
# file: appdir/file1
# owner: root
# group: root
user::rw-
group::rwx #effective:rw-
group:testusers:r-- mask::rw-
other::r--
Remove the acl for testuser1 on appuser1 directory
setfacl -x u:testuser1 appdir/
-----------------------------------------------------------------------------------------------------------------------
SELinux
========
sestatus
SELinux status: enabled
SELinuxfs mount: /selinux
ps axZ | grep httpd
system_u:system_r:httpd_t 3234 ? Ss 0:00 /usr/sbin/httpd
Finally, let's look at the SELinux security context of a file in our home directory:
$ ls -Z /home/username/myfile.txt
-rw-r--r-- username username user_u:object_r:user_home_t /home/username/myfile.txt
The 'chcon' command may be used to change SELinux security context of a file or files/directories
mkdir /html
# touch /html/index.html
# ls -Z /html/index.html
-rw-r--r-- root root user_u:object_r:default_t /html/index.html
# ls -Z | grep html
drwxr-xr-x root root user_u:object_r:default_t html
chcon -v --type=httpd_sys_content_t /html
context of /html changed to user_u:object_r:httpd_sys_content_t
# chcon -v --type=httpd_sys_content_t /html/index.html
context of /html/index.html changed to user_u:object_r:httpd_sys_content_t
# ls -Z /html/index.html
-rw-r--r-- root root user_u:object_r:httpd_sys_content_t /html/index.html
# ls -Z | grep html
drwxr-xr-x root root user_u:object_r:httpd_sys_content_t html
Equally we could have set both in one go using the -R recursive switch:
# chcon -Rv --type=httpd_sys_content_t /html
To make the security context changes permanent, even through a complete filesystem relabel, we can use the SELinux Management Tool or the 'semanage' command from the command line:
semanage fcontext -a -t httpd_sys_content_t "/html(/.*)?"
Restore Default Security Contexts
restorecon -Rv /var/www/html
Allowing Access to a Port
semanage port -a -t http_port_t -p tcp 81
semanage port -l
-----------------------------------------------------------------------------------------------------------------
SETUID SETGUID AND STICKY BIT PERMISSION
--------------------------------------
A lower case s is used where the execute bit is on, and an upper case S where the execute bit is not set.
SUID (Set User ID) => When a SUID bit is set on a command then that command always executes with the User ID of its own user owner (who created it) instead of the user who is executing it.
EXAMPLE: The binary of passwd command has SUID permission set on it, that is why, when unpriviledged users execute this command, it always executes with the UID of "root" and changes their password in /etc/shadow (which is only readable or writable by root).
To set SUID on a program, run:
[kh@server ~]$ chmod u+s "/path/to/command/binary"
4755, would set the setuid bit (4)
SGID (Set Group ID)(on command binary) => When SGID permission is set on any command, then that command runs with the Group ID of group owner of the command's binary instead of GID of the user who is executing it. To set SGID on a program, run:
[kh@server ~]$ chmod g+s "/path/to/command/binary"
SGID (Set Group ID)(on directories) => When SGID permission is set on a directory, then all the new (future) files created under that directory will have the same group owner as that of the parent directory. Moreover subdirectories (created in future) will also have SGID bit on them. Example: If we set SGID on a directory, for example: on /tmp/test with group owner as "john", now if another user "mike" creates any file in /tmp/test directory then the user owner of this file will be "mike" but group owner will be "john" because of SGID on parent directory. To set SGID on a directory, run:
[kh@server ~]$ chmod g+s /path/to/directory
Sticky Bit => The new files created under the directory having Sticky Bit on it can be only deleted by root or the user who created that file. No other user can delete that file even if they have write permission on the parent directory. EXAMPLE: /tmp directory is having Sticky Bit permission on it, that is why the content under this can be only deleted by root or the user owner of the content/file. To set Sticky Bit on a directory, run:
[kh@server ~]$ chmod o+t /path/to/directory
» 27072 reads
Comments
Post a Comment