2. SYSTEM SECURITY
HOST SECURITY
Host security describes how your server is set
up for the following tasks:
• Preventing attacks.
• Minimising the impact of a successful attack
on the overall system.
• Responding to attacks when they occur.
It always helps to have software with no
security holes. In the real world, the best
approach for preventing attacks is to assume
your software has security holes. each service
you run on a host presents a distinct attack
vector into the host.
3. The more attack vectors, the more likely an
attacker will find one with a security exploit.
You must therefore minimize the different
kinds of software running on a server.
Given the assumption that your services are
vulnerable , your most significant tool in
preventing attackers from exploiting a
vulnerability once it becomes known is the
rapid rollout of security patches. Here’s where
the dynamic nature of the cloud really alters
what you can do from a security perspective.
In a traditional data center , rolling out
security patches across an entire
infrastructure is time consuming and risky.
4. In the cloud, rolling out a patch across the
infrastructure takes 3 simple steps:
1. Patch your AMI with the new security
fixes.
2. Test the result.
3. Relaunch your virtual servers.
5. TCP WRAPPERS
• TCP Wrappers (also known as
tcp_wrappers) is a host-based networking ACL
system, used to filter network access to
Internet Protocol servers on (Unix-like) operating
systems such as Linux or BSD.
• It allows host or subnetwork IP addresses,
names and/or ident query replies, to be used as
tokens on which to filter for access control
purposes.
• TCP Wrapper is a public domain computer
program that provides firewall services for UNIX
servers. The program was developed by Wietse
Venema.
6. When an unprotected UNIX computer is connected
to a network, the computer's system is exposed to
other computer users connected to the network.
For example, by using the finger utility, a hacker may
be able to determine which users are logged on to a
given server. It is also possible to find out the
identities of individual computers, and various
details about their users' recent Internet behavior. A
hacker can determine when a workstation is likely to
be idle, and then access and use that workstation
when it is unattended. TCP Wrapper can act as a
firewall to prevent this.
7. TCP Wrapper monitors incoming packets. If an
external computer or host attempts to connect, TCP
Wrapper checks to see if that external entity is
authorized to connect. If it is authorized, then
access is permitted; if not, access is denied. The
program can be tailored to suit individual user or
network needs.
Before we start, however, we must clarify that the
use of TCP wrappers does not eliminate the need
for a properly configured firewall.
8. UNDERSTANDING HOSTS.ALLOW
AND HOSTS.DENY
• TCP wrappers rely on two configuration files as the
basis for access control:
• /etc/hosts.allow
• /etc/hosts.deny
• When a client attempts to connect to a network
service on a remote system, these files are used to
determine whether client access is allowed or
denied. Use /etc/hosts.allow and /etc/hosts.deny to
define rules that selectively allow or deny clients
access to server daemons on local system.
9. • When a network request reaches your server,
TCP wrappers uses hosts.allow and
hosts.deny (in that order) to determine if the
client should be allowed to use a given service.
• By default, these files are empty, all commented
out, or do not exist. Thus, everything is allowed
through the TCP wrappers layer and your system
is left to rely on the firewall for full protection.
make sure both files exist:
• # ls -l /etc/hosts.allow /etc/hosts.deny
• The syntax of both files is the same:
• <services> : <clients> [: <option1> : <option2]
10. • services is a comma-separated list of services.
• clients represent the list of comma-separated
hostnames or IP addresses .The following wildcards
are accepted:
• ALL matches everything. Applies both to clients and
services.
• LOCAL matches hosts without a period in their
FQDN, such as localhost.
• KNOWN indicate a situation where the hostname,
host address, or user are known.
• UNKNOWN is the opposite of KNOWN.
11. To allow client access, add the client host
name or IP address in /etc/hosts.allow. To
deny client access, add its name or IP
address in /etc/hosts.deny.
The /etc/hosts.allow file is read first and is
read from top to bottom. If a service-client
pair matches the first line in the file,
access is granted. If the line is not a
match, the next line is read and the same
check is performed. If all lines are read
and no match occurs, the /etc/hosts.deny
file is read, starting at the top.
12. If a service-client pair match is found in the
deny file, access is denied. If no rules for the
daemon-client pair are found in either file, or
if neither file exists, access to the service is
granted.
Because access rules in hosts.allow are
applied first, they take precedence over rules
specified in hosts.deny. Therefore, if access to
a service is allowed in hosts.allow, a rule
denying access to that same service in
hosts.deny is ignored.
13. • You may want to keep in mind that a rule allowing
access to a given service in /etc/hosts.allow takes
precedence over a rule in /etc/hosts.deny
prohibiting it. Additionally, if two rules apply to the
same service, only the first one will be taken into
account.
• Unfortunately, not all network services support the
use of TCP wrappers. To determine if a given service
supports them, do:
• # ldd /path/to/binary | grep libwrap
• If the above command returns output, it can be
TCP-wrapped.
14. How to Use TCP Wrappers to Restrict Access to Services
• As you edit /etc/hosts.allow and /etc/hosts.deny,
make sure you add a newline by pressing Enter after
the last non-empty line.
• To allow SSH and FTP access only to 192.168.0.102
and localhost and deny all others, add these two lines
in /etc/hosts.deny:
sshd,vsftpd : ALL
and the following line in /etc/hosts.allow:
shd,vsftpd : 192.168.0.102,LOCAL
ALL : ALL (accept all connections to any service.)
15. /ETC/SECURITY
This /etc/security directory contains the
user and group configuration files and the
encrypted passwords.
The /etc/security directory contains
sensitive files such as
/etc/security/passwd, /etc/security/group. It
must be secured from unauthorized access
and modifications.
/etc/security/audit/config - Contains
audit system configuration information.
/etc/security/environ - Contains the
environment attributes of users.
16. /etc/security/limits - Contains the process
resource limits of users.
/etc/security/login.cfg - Contains
configuration information for user log in and
authentication.
/etc/security/user - Contains extended user
attributes.
/etc/security/lastlog - Contains last login
information.
17. /ETC/SECURITY/PASSWD FILE
The /etc/security/passwd file is an ASCII
file that contains stanzas with password
information. Each stanza is identified by a
user name followed by a : (colon) and contains
attributes in the form Attribute=Value. Each
attribute is ended with a new line character,
and each stanza is ended with an additional
new line character.
Each stanza can have the following
attributes:
18. password - Specifies the encrypted
password. The system encrypts the password
created with the passwd command or
the pwdadm command. If the password is
empty, the user does not have a password. If
the password is an * (asterisk), the user
cannot log in. The value is a character string.
The default value is *.
lastupdate - Specifies the time (in seconds)
when the password was last changed. If
password aging is in effect,
the lastupdate attribute forces a password
change when the time limit expires.
19. flags - Specifies the restrictions applied by
the login, passwd, and su commands. The
value is a list of comma-separated attributes.
The flags attribute can be left blank or can be
one or more of the following values:
• ADMIN
Defines the administrative status of the
password information. If the ADMIN attribute
is set, only the root user can change this
password information.
• ADMCHG
Indicates that the password was last
changed by a member of the security group or
the root user.
20. • NOCHECK
None of the system password restrictions
defined in the /etc/security/user file are
enforced for this password.
The following line indicates that the password
information in the /etc/security/passwd file
is available only to the root user, who has no
restrictions on updating a password for the
specified user:
flags = ADMIN,NOCHECK
An example of this line in a typical stanza for
user smith follows:
22. /ETC/SECURITY/GROUP FILE
The /etc/security/group file contains extended
group attributes. This is an ASCII file that
contains a stanza for each system group. Each
stanza is identified by a group name from
the /etc/group file followed by a : (colon) and
contains attributes in the form Attribute=Value.
Each attribute pair ends with a new-line
character as does each stanza. The file supports
a default stanza. If an attribute is not defined
for a group, the default value for the attribute is
used.
A stanza can contain one or more of the
following attributes:
23. • adms - Defines the group administrators.
The value is a list of comma-separated
user login-names. The default value is an
empty string.
• admin - Defines the administrative status
of the group. Possible values are:
true-Defines the group as administrative.
Only the root user can change the attributes of
groups defined as administrative.
false-Defines a standard group. The
attributes of these groups can be changed by
the root user or a member of the security group.
This is the default value.
24. • efs_keystore_access - Defines the group
keystore location. You can specify the following
values:
none - There is no keystore.
File - Keystore is stored in the /var/efs/groups/
directory.
• efs_keystore_algo - Defines the algorithm
that is used to generate the group private key.
You can specify the following values:
RSA_1024
RSA_2048
RSA_4096
25. A typical stanza looks like the following
example for the finance group:
finance:
admin = false
adms = cjf, scott, sah
26. THE /ETC/PASSWD FILE
The /etc/passwd file is a list of users recognized by
the system. The system consults the file at login
time to determine a user’s UID and home directory,
among other things. Each line in the file represents
one user and contains seven fields separated by
colons:
• Login name
• Encrypted password or password placeholder
• UID (user ID) number
• Default GID (group ID) number
27. • “GECOS” information: full name, office, extension,
home phone
• Home directory
• Login shell
For example, the following lines are all syntactically
valid /etc/passwd entries:
root:lga5FjuGpZ2so:0:0:The System,,x6096,:/:/bin/sh
jl:x:100:0:Jim Lane,ECT8-3,,:/staff/jl:/bin/sh
dotty:
$1$Ce8QpAQI$L.DvJEWiHlWetKTMLXFZO/:101:20::/
home/dotty:/bin/tcsh
28. These days it is not acceptable to leave encrypted
passwords in plain view. With fast hardware, they
can be “cracked” in minutes. All versions of UNIX
and Linux allow you to hide the encrypted
passwords by placing them in a separate file that is
not world-readable. This is known as a shadow
password mechanism, and it is (appropriately) the
default on most systems.
29. Login name:
Login names (also known as usernames) must
be unique and no more than 32 characters long.
They may contain any characters except colons
and newlines. If you use NIS, login names are
limited to 8 characters, regardless of the
operating system.
Login names are case sensitive.
Login names should be unique in two senses.
First, a user should have the same login name
on every machine. This rule is mostly for
convenience, both yours and the user’s. Second,
a particular login name should always refer to
the same person.
30. Encrypted password:
Passwords are stored in an encrypted
form.You must either set passwords by using
the passwd command (yppasswd if you use
NIS) or by copying an encrypted password
string from another account.
If you edit /etc/passwd by hand to create a
new account, put a star or an x in the
encrypted password field. The star prevents
unauthorized use of the account until you
have set a real password. Never leave this
field empty.
31. Major Linux distributions recognize multiple
methods of password encryption, and they can
determine the encryption method used for
each password by examining the encrypted
data.
Most Linux distributions default to using MD5
encryption.
Encrypted passwords are of constant length
(34 characters long for MD5, 13 for DES)
32. UID (user ID) number:
UIDs are unsigned 32-bit integers. However,
because of interoperability issues with older
systems, we suggest limiting the largest UID
at your site to 32,767 (the largest signed 16-bit
integer) if possible.
By definition, root has UID 0. UIDs to real
users starts at 500 (or higher).
UIDs should be kept unique. That is, a
particular UID should refer to the same login
name and the same person on every machine.
33. Default GID number:
Like a UID, a group ID number is 32-bit
integer. GID 0 is reserved for the group called
“root”. GID 1 is the group “bin” and GID 2 is
the group “daemon”.
Groups are defined in /etc/group, with the
GID field in /etc/passwd providing the
default (or “effective”) GID at login time.
34. GECOS field:
The GECOS field is commonly used to record
personal information about each user.
It has no well-defined syntax.
It may be comma seperated GECOS entries
in the following order.
• Full name (often the only field used)
• Office number and building
• Office telephone extension
• Home phone number
These days,only the name remains.
35. Home directory:
Users’ shells are cd’ed to their home
directories when they log in. If a user’s home
directory is missing at login time, the system
prints a message such as “no home directory.”5
If DEFAULT_HOME is set to no in
/etc/login.defs, the login will not be allowed
to continue; otherwise, the user will be placed
in the root directory.
36. Login shell:
The login shell is normally a command
interpreter such as the Bourne shell or the C
shell (/bin/sh or /bin/csh), but it can be any
program. bash is the default and is used if
/etc/passwd does not specify a login shell.
Users can change their shells with the chsh
command. The file /etc/shells contains a list
of “valid” shells that chsh will permit users
to select.
37. This features stores the encrypted passwords
in a separate file, /etc/shadow and the
encrypted-password field of the /etc/passwd file
is to an asterisk. The new shadow file,
/etc/shadow, is set so that only the superuser
can read the file and the original file,
/etc/passwd, remains readable by anyone.
The problem with the original password file
scheme is that even with a one-way encryption
algorithm for the password field, intruder were
taking copies of the /etc/passwd file and using
common words as guesses.
SHADOW PASSWORD
38. Since many users set their passwords to
common words (their family names, common
computer terms, common words backwords,
and the like) a brute force search would often
yield numerous valid passwords.
Another feature that was introduced with
shadow passwords is password aging. This
allows the system administrator to specify
both the minimum and maximum number of
days between passwords changes for a user.
39. THE /ETC/SHADOW FILE
/etc/shadow contains one line for each user.
Each line contains nine fields, separated by
colons:
• Login name
• Encrypted password
• Date of last password change
• Minimum number of days between password
changes
• Maximum number of days between password
changes
40. • Number of days in advance to warn users about
password expiration
• Number of days after password expiration that
account is disabled
• Account expiration date
• A reserved field that is currently always empty.
The only fields that are required to be nonempty
are the username and password.
Here is a more complete description of each
field:
• The login name is the same as in /etc/passwd.
This field connects a user’s passwd and shadow
entries.
41. • The encrypted password is identical in concept and
execution to the one previously stored in /etc/passwd.
• The last change field records the time at which the
user’s password was last changed. This field is
generally filled in by passwd.
• The fourth field sets the number of days that must
elapse between password changes. The idea is to force
authentic changes by preventing users from
immediately reverting to a familiar password after a
required change.
• The fifth field sets the maximum number of days
allowed between password changes. This feature allows
the administrator to enforce password aging.The actual
enforced maximum number of days is the sum of this
field and the seventh (grace period) field.
42. • The sixth field sets the number of days before
password expiration that the login program
should begin to warn the user of the impending
expiration.
• The seventh field specifies how many days
after the maximum password age has been
reached to wait before treating the login as
expired.
• The eighth field specifies the day (in days
since Jan 1, 1970) on which the user’s account
will expire. The user may not log in after this
date until the field has been reset by an
administrator. If the field is left blank, the
account will never expire.
43. • The ninth field is reserved for future use.
A typical shadow entry looks like this:
millert:
$1$buJ6v3Ch$BwLIoF5eaCh9Nv.OEzD3T0:133
48:0:180:14::14974:
In this example, the user millert last
changed his password on July 18, 2006. The
password must be changed again within 180
days, and millert will receive warnings that the
password needs to be changed for the last two
weeks of this period. The account expires on
December 31, 2010.
44. FILE PERMISSIONS
Linux is a clone of Unix, the Multiuser operating
system which can be accessed by many users
simultaneously.
• Linux can also be used in mainframe and
service with any modifications.
• The effective security, Linux divided
authorization in 2 level.
1) ownership
2) permission
45. Ownership of Linux file:
Every file and directory on your Unix Or
Linux system is assigned 3 type of owner.
1) User
The user is the owner of the file. By defines
the person who created a file become it’s
owner. Hence, a user is also some time called
an owner.
2) Group
A user group can contains multiple user. All
user’s belonging to a group will have the same
Linux group permission access to the file.
46. Instead of manually assigning permission to
each users, you could add all users to a group,
and assign group permission to file such that
only this group members and no one can read
or modify the file.
3) Others
Any other user who has access to a file hence
when you set the permission for others, it is
also retrieved as set permission for the world.
47. Every file and directory in your Linux
system has 3 permission
1) Read
This permission give you the authority to open
and read a file. Read permission on a directory
gives you the ability to lists its content.
2) write
The write permission gives you the authority
to modify the content of a file. The write
permission on a directory gives you the
authority to add, remove and renames file
stored in the directory.
48. 3)Execute
In windows, an executable program usually has an
extension exe and which you can easily run in Unix,
you cannot run a program unless the execute.
Chmod command:
Syntax:
Chmod permission file name
‘Chmod’ command which stands for change mod,
using the command, we can set permission (read,
write, execute) on a file or directory for the owner,
group and the world.
There are 2 ways to use the command
1) Absolute mode
2) Symbolic mode
49. Absolute mode:
In this mode, file permission are represented
as character but 3 digit octal numbers.For
representing the permission following digits
are used:
Octal binary Description Permissions
0 000 no permission ---
1 001 Execute --x
2 010 Write -w-
3 011 Read r--
4 100 Execute,write -wr
5 101 Read,Execute r-x
6 110 Read,write rw-
7 111 Read,write,execute rwx
50. Symbolic mode:
This mode permits both addition and deletion of
permission.The general format is:
Syntax:
chmod [who] [+/-/=] permission filename
where who stands for the permission to the
owner,group,other and all. Group notation are:
U : user or owner ,G : group ,O : other , A : all.
- :Remove the permission.
+ : add a permission to a file or directory.
= : set the permission and override the
permission set earlier.
51. ADDING USERS: THE BASIC STEPS
Required:
• Have the new user sign your policy
agreement.
• Edit the passwd and shadow files to define
the user’s account.
• Add the user to the /etc/group file (not really
necessary, but nice).
• Set an initial password.
• Create, chown, and chmod the user’s home
directory.
• Configure roles and permissions
52. For the user:
• Copy default startup files to the user’s home
directory.
• Set the user’s mail home and establish mail
aliases.
For you:
• Verify that the account is set up correctly.
• Add the user’s contact information and
account status to your database.
You must perform each step as root or use a
program such as sudo.
53. EDITING THE PASSWD AND
GROUP FILES
If you have to add a user by hand, use vipw
to edit the passwd and shadow files.
If the new user should be a member of more
groups than just the default group
specified in the passwd file, you must edit
the /etc/group file and add the user’s
login name to each of the additional groups.
54. EDITING THE /ETC/GROUP
FILE
We should next create an entry in the
/etc/group file.
This group should have GID.
The kernel doesn’t care about the contents
of /etc/passwd and /etc/group; it only cares
about UID and GID numbers. The main
purpose of recording personal groups in the
group file is to make sure that commands
such as ls display the names of these
groups correctly.
55. SETTING A PASSWORD
Root can change any user’s password with the
passwd command:
# passwd user
or
$ sudo passwd user
passwd prompts you to enter a new password
and asks you to repeat it. If you choose a short,
all-lowercase, or otherwise obviously
unsuitable password, passwd will complain
and ask you to use something more complex.
Never leave a new account—or any account
that has access to a shell—without a
password.
56. CREATING THE HOME
DIRECTORY AND INSTALLING
STARTUP FILES
You can create the new user’s home
directory with a simple mkdir. You’ll need
to set ownerships and permissions on the
new directory as well, but this is best done
after you’ve installed any local startup files.
Any directory you create as root is initially
owned by root, so you must change its
owner and group with the chown and chgrp
commands.
57. Sample startup files are traditionally kept in
/etc/skel (Linux, Solaris, HP-UX) or /etc (all
systems).
If you customize your vendor’s startup file
examples, /usr/local/etc/skel is a reasonable
place to put the modified copies. Linux also
keeps tidbits of startup files in the /etc/profile.d
directory.
A new user’s home directory is populated with
startup files from /etc/skel.For example, bash
and sh read /etc/profile before processing
~/.profile and ~/.bash_profile ( contain default
value)
58. SETTING PERMISSIONS AND
OWNERSHIPS
Now that the home directory is set up, turn
it over to the user and make sure that the
permissions on it are appropriate. The
command
$ sudo chown -R newuser:newgroup ~newuser
should set ownerships properly.
59. SETTING A MAIL HOME
It is convenient for each user to receive email
on only one machine.
This scheme is often implemented with an
entry in the global aliases file
/etc/mail/aliases or the sendmail userDB on
the central mail server.
60. CONFIGURING ROLES AND
ADMINISTRATIVE
PRIVILEGES
Role-based access control (RBAC) allows system
privileges to be tailored for individual users and is
available on many of our example systems. RBAC is
not a traditional part of the UNIX or Linux access
control model, but if your site uses it,role
configuration must be a part of the process of
adding users.
61. VERIFYING THE NEW LOGIN
To verify that a new account has been
properly configured, first log out, then log
in as the new user and execute the
following commands:
$ pwd /* To verify the home directory */
$ ls -la /* Check owner/group of startup files
*/
You will need to notify new users of their
login names and initial passwords. Many
sites send this information by email, but for
security reasons that’s usually not a good
idea.
62. RECORDING THE USER’S
STATUS AND CONTACT
INFORMATION
Maintaining a database of contact
information and account statuses will help
you figure out who someone is and why
they have an account, once the act of
adding them has faded from memory.
It’s a good idea to keep complete contact
information on hand so that you can reach
users in the event of problems or
misbehavior.
63. ADDING USERS WITH USERADD
Each system’s useradd implements the
same basic procedure outlined above.
useradd on Ubuntu:
Ubuntu provides two ways to add users:
adduser and useradd.
adduser is configured in /etc/adduser.conf,
which includes options such as these:
• Rules for locating home directories: by
group, by username, etc.
• Permission settings for new home directories
64. • UID and GID ranges for system users and
general users
• An option to create individual groups for
each user
• Disk quotas (Boolean only, unfortunately)
• Regex-based matching of usernames and
group names
To create a new user “hilbert” using the
system defaults on a Linux system, you
could simply run
$ sudo useradd hilbert
65. This command would create the following entry
in /etc/passwd:
hilbert:x:1005:20::/home/hilbert:/bin/sh
useradd disables the account by putting an x in
the password field. You must assign a real
password to make the account usable.
66. ADDING USERS IN BULK WITH
NEWUSERS (LINUX)
Linux’s newusers creates multiple accounts at
one time from the contents of a text file when
you need to add a lot of users at once, such as
when creating class-specific accounts.
newusers expects an input file of lines just like
the /etc/passwd file, except that the password
field contains the initial password in clear
text.
. The only startup file it provides is .xauth.
67. REMOVING USERS
When a user leaves your organization, that
user’s login account and files should be
removed from the system. This procedure
involves the removal of all references to the
login name that were added by you or your
useradd program. If you remove a user by
hand, you may want to use the following
checklist:
• Remove the user from any local user
databases or phone lists.
• Remove the user from the aliases file or add a
forwarding address.
68. • Remove the user’s crontab file and any
pending at jobs or print jobs.
• Kill any of the user’s processes that are still
running.
• Remove the user from the passwd,
shadow,group, and gshadow files.
• Remove the user’s home directory.
• Remove the user’s mail spool.
• Clean up entries on shared calendars, room
reservation systems, etc.
• Delete or transfer ownership of any mailing
lists run by the deleted user
69. TO CHECK USER EXIST
Once you have removed a user, you may want
to verify that the user’s old UID no longer
owns files on the system.For this,you can use
the find command with the -nouser argument.
$ sudo find filesystem -xdev -nouser
70. DISABLING LOGINS
On all our Linux distributions, the usermod
-L user and usermod -U user commands
provide an easy way to lock and unlock
passwords. They are just shortcuts for the
password twiddling described above: the -L
puts an ! in front of the encrypted password
in the /etc/shadow file, and the -U removes
it.
71. USERS GROUPS
In Linux, groups are collections of users.
Creating and managing groups is one of the
simplest ways to deal with multiple users
simultaneously, especially when dealing with
permissions. The /etc/group file stores group
information and is the default configuration
file.
72. THE /ETC/GROUP FILE
The /etc/group file contains the names of
UNIX groups and a list of each group’s
members.
Each line represents one group and contains
four fields:
• Group name
• Encrypted password or a placeholder
• GID number
• List of members, separated by commas (be
careful not to add spaces)
73. As in /etc/passwd, fields are separated by
colons. Group names should be limited to
eight characters for compatibility.
Some systems limit the number of groups a
user can belong to. Eight groups used to be a
common limit, but it is now 16 on Solaris, 20
on HP-UX, and seemingly unlimited on AIX
and Linux.
The useradd utilities on all of our Linux
distributions except SUSE default to placing
users in their own personal groups.
74. The UNIX systems default to putting all
new users in the same group, but their
useradds can be configured to support
personal groups, too.
A user’s personal group should contain only
that user. If you want to let users share
files by way of the group mechanism, create
separate groups for that purpose.
Linux, Solaris, and HP-UX all supply
commands that create, modify, and delete
groups: groupadd, groupmod, groupdel. AIX
instead expects you to modify the /etc/group
file with a text editor. However, it does
provide the grpck command to check the
file’s syntax.
76. UMASK: ASSIGN DEFAULT
PERMISSIONS
You can use the built-in shell command
umask to influence the default permissions
given to the files you create.
The umask is specified as a three-digit octal
value that represents the permissions to
take away.
When a file is created, its permissions are
set to whatever the creating program
requests minus whatever the umask
forbids. Thus,the individual digits of the
umask allow the permissions shown in
Table
78. Bonus flags:
Linux’s ext2fs and ext3fs filesystems define
some supplemental attributes you can turn on
to request special filesystem semantics.
Flag Meaning
A Never update access time
(st_atime; for performance)
a Allow writing only in append mode
(only root can set)
D Force directory updates to be
written synchronously
d No backup—make dump ignore
this file
79. i Make file immutable and
undeletable (only root can set)
j Keep a journal for data changes as
well as metadata
S Force changes to be written
synchronously (no buffering
![• When a network request reaches your server,
TCP wrappers uses hosts.allow and
hosts.deny (in that order) to determine if the
client should be allowed to use a given service.
• By default, these files are empty, all commented
out, or do not exist. Thus, everything is allowed
through the TCP wrappers layer and your system
is left to rely on the firewall for full protection.
make sure both files exist:
• # ls -l /etc/hosts.allow /etc/hosts.deny
• The syntax of both files is the same:
• <services> : <clients> [: <option1> : <option2]](https://image.slidesharecdn.com/linuxunit2part3notes-250315060133-2fd17b84/85/Linux-unit-2-part-3-notes-pptxl-lk-l-k-9-320.jpg)
![Symbolic mode:
This mode permits both addition and deletion of
permission.The general format is:
Syntax:
chmod [who] [+/-/=] permission filename
where who stands for the permission to the
owner,group,other and all. Group notation are:
U : user or owner ,G : group ,O : other , A : all.
- :Remove the permission.
+ : add a permission to a file or directory.
= : set the permission and override the
permission set earlier.](https://image.slidesharecdn.com/linuxunit2part3notes-250315060133-2fd17b84/85/Linux-unit-2-part-3-notes-pptxl-lk-l-k-50-320.jpg)
