Tải bản đầy đủ (.pptx) (50 trang)

Computer security principles and practice 3rd by williams stallings and brown ch25

Bạn đang xem bản rút gọn của tài liệu. Xem và tải ngay bản đầy đủ của tài liệu tại đây (689.7 KB, 50 trang )

© 2016 Pearson
Education, Inc.,
Hoboken, NJ. All rights
reserved.


Chapter 25
Linux Security

Contributed by:
Mick Bauer
Security Editor, Linux Journal
Dir. of Value-Subtracted Svcs., Wiremonkeys.org

© 2016 Pearson Education, Inc.,
Hoboken, NJ. All rights reserved.


Linux
• Created in 1991 by Linus Torvalds
• Has evolved into one of the world's most popular
and versatile operating systems
o Free
o Open-sourced
o Available in a wide variety of distributions targeted at almost every
usage scenario imaginable

• Examples of distributions include:
o Red Hat Enterprise Linux
• Conservative and commercially supported
o Ubuntu


• Completely free
o uClinux
• Stripped-down but hyper-stable embedded version designed for
use in appliances and consumer products
© 2016 Pearson Education, Inc.,
Hoboken, NJ. All rights reserved.


Linux Security
The traditional Linux security model can be summed up quite
succinctly: People or processes with “root” privileges can do
anything; other accounts can do much less

From the attacker’s perspective the challenge in cracking a
Linux system is gaining root privileges

Once an attacker gains root privileges they can:




Erase or edit logs
Hide their processes, files, and directories
Basically redefine the reality of the system as experienced by its administrators
and users

Thus, Linux security (and UNIX security in general) is a game
of “root takes all”
© 2016 Pearson Education, Inc.,
Hoboken, NJ. All rights reserved.



Discretionary Access
Controls (DAC)
In the Linux
DAC system
there are

Linux’s
security
model

Each object
has three
sets of
permissions:

• Users: each
of which
• User-owner
belongs to
• Group-owner
one or more Users read, • Other
groups
(everyone
write, and
• Objects:
execute the else)
files and
objects

directories

based on
the object’s
permissions

© 2016 Pearson Education, Inc., Hoboken, NJ. All rights reserved.

Permissions
are
enforced by
the Linux
kernel


Permissions
Prior to being executed a program’s file-permissions restrict who can execute,
access, or change it

When running, a process normally runs as the identity of the user and group
of the person or process that executed it

If a running process attempts to read, write, or execute some other object
the kernel will first evaluate that object’s permissions against the process’s
user and group identity

Whoever owns an object can set or change its permissions

The system superuser account has the ability to both take ownership and change
the permissions of all objects in the system


© 2016 Pearson Education, Inc., Hoboken, NJ. All rights reserved.


© 2016 Pearson Education, Inc., Hoboken, NJ. All rights reserved.


DAC
In a sense Linux treats
everything as a file

To the Linux kernel the CDROM drive attached to your
system is also a file
(/dev/cdrom)
• To send data to and from the CDROM drive the Linux kernel actually
reads to and writes from this file

In UNIX a directory is
actually a file containing a
list of other files

Other special files, such as
named pipes, act as
input/output (I/O) conduits
allowing one process or
program to pass data to
another

• One example of a named pipe on
Linux systems is /dev/urandom

(returns random characters from
the kernel’s random number
generator)
© 2016 Pearson Education, Inc., Hoboken,
NJ. All rights reserved.


Users, Groups, and
Permissions
• There are two things on a UNIX system that aren’t
represented by files:
o User accounts
o Group accounts

• User account
o Represents someone or something capable of using files
o Can be associated with both actual human beings and
processes

• Group account
o A list of user accounts
o Each user account is defined with a main group membership,
but may belong to as many groups as you need it to

© 2016 Pearson Education, Inc., Hoboken, NJ. All rights reserved.


Users, Groups, and
Permissions
maestro:x:200:100:Maestro Edward

Hizzersands:/home/maestro:/bin/bash

Listing 25-1: An /etc/password Entry For the User
"maestro”
conductors:x:100:
pianists:x:102:maestro,volodya

Listing 25-2: Two /etc/group Entries

© 2016 Pearson Education, Inc., Hoboken, NJ. All rights reserved.


Simple File Permissions
• Each file on a UNIX system has two owners (a
user and a group)
• Each user and group has its own set of
permissions that specify what the user or group
may do with the file (read it, write to it, delete it,
execute it)
• Other
o User accounts that don’t own the file or belong to the group
that owns it

• Listing 25-3 shows a long file-listing for the file
/home/maestro/baton_dealers.txt
-rw-rw-r-- 1 maestro conductors 35414 Mar 25 01:38 baton_dealers.txt
Listing 25-3: File-Listing Showing Permissions
© 2016 Pearson Education, Inc., Hoboken, NJ. All rights reserved.



Directory Permissions
Execute translates to “use anything
within or change working directory to
this directory”

If a user or group has execute
permissions on a given directory the
user or group can list that directory’s
contents, read that directory’s files,
and change its own working directory
to that directory

If a user or group does not have
execute permissions on a given
directory it will be unable to list or
read anything in it, regardless of the
permissions set on the things inside

© 2016 Pearson Education, Inc., Hoboken, NJ. All rights reserved.


Listing 25-4:
A Group-Readable
Directory
bash-$ chmod g+rx extreme_casseroles
bash-$ ls -l extreme_casseroles
drwxr-x--- 8 biff drummers 288 Mar 25 01:38
extreme_casseroles

© 2016 Pearson Education, Inc.,

Hoboken, NJ. All rights reserved.


The Sticky Bit
• In older UNIX operating systems the sticky bit was
used to write a file (program) to memory so it
would load more quickly when invoked
• The sticky bit is used to allow someone with
“write” permissions to create new files in the
directory but not delete any files
• On Linux when you set the sticky bit on a
directory, it limits users’ ability to delete things in
that directory
o To delete a given file in the directory you must either own that file or
own the directory, even if you belong to the group that owns the
directory and group-write permissions are set on it

• To set the sticky bit, issue the command:
chmod +t directory_name
© 2016 Pearson Education, Inc.,
Hoboken, NJ. All rights reserved.


Contents of
extreme_casseroles/
drwxrwxr-T 3 biff drummers 192 2004-08-10 23:39 .
drwxr-xr-x 3 biff drummers 4008 2004-08-10 23:39
..
-rw-rw-r-- 1 biff drummers
18 2004-07-08 07:40

chocolate_turkey_casserole.txt
-rw-rw-r-- 1 biff drummers
12 2004-08-08 15:10
pineapple_mushroom_suprise.txt
drwxr-xr-x 2 biff drummers
80 2004-08-10 23:28
src
© 2016 Pearson Education, Inc.,
Hoboken, NJ. All rights reserved.


Attempting Deletion With Stickybit Set
(user input in boldface)

crash@localhost:/extreme_casseroles> rm
pineapple_mushroom_suprise.txt
rm: cannot remove `pineapple_mushroom_suprise.txt':
Operation not permitted

© 2016 Pearson Education, Inc.,
Hoboken, NJ. All rights reserved.


Setuid and Setgid
Two of the most
dangerous
permissions bits in
UNIX

If set on an

executable binary
file the setuid bit
causes that
program to run as
its owner no
matter who
executes it

If set on an
executable the
setgid bit causes
that program to
run as a member
of the group that
owns it regardless
of who executes it

Very dangerous if
set on any file
owned by root or
any other
privileged account
or group

© 2016 Pearson Education, Inc.,
Hoboken, NJ. All rights reserved.


Setgid and Directories
Setuid has no effect on

directories but setgid
does

Setting a directory’s
setgid bit causes any
file created in that
directory to inherit the
directory’s group-owner

• This is useful if users
on your system tend
to belong to
secondary groups and
routinely create files
that need to be
shared with other
members of those
groups

If the directory isn’t
group-writable the
setgid bit will have no
effect because group
members won’t be able
to create files inside it
© 2016 Pearson Education, Inc.,
Hoboken, NJ. All rights reserved.


Numeric Modes

• Internally Linux uses numbers to represent
permissions
• Consists of four digits
o As you read left to right these represent special permissions, user
permissions, group permissions, and other permissions

• Each permission has a numeric value and the
permissions in each digit-place are additive
o The digit represents the sum of all permission-bits you wish to set

• Basic numeric values are 4 for read, 2 for write,
and 1 for execute
o These values represent bits in a binary stream and are therefore all
powers of 2
o If user permissions are set to “7” this represents 4(value for read) plus
2 (the value for write and 1 (the value for execute)
© 2016 Pearson Education, Inc.,
Hoboken, NJ. All rights reserved.


Special
Permission
s
4 stands for setuid,
2 stands for setgid,
1 stands for stickybit

For example, the
numeric mode 3000
translates to

"setgid set, sticky-bit
set, no other
permissions set"
(which is, actually, a useless
set of permissions)

© 2016 Pearson Education, Inc.,
Hoboken, NJ. All rights reserved.


© 2016 Pearson Education, Inc.,
Hoboken, NJ. All rights reserved.


Kernel Space Versus
User Space
Kernel Space
• Refers to memory used by
the Linux kernel and its
loadable modules
o e.g., device drivers

• Because the kernel enforces
the Linux DAC it is extremely
important to isolate kernel
space from user space
o For this reason kernel space is never
swapped to hard disk
o It is also the reason that only root may
load and unload kernel modules

© 2016 Pearson Education, Inc., Hoboken, NJ. All rights reserved.

User Space
• Refers to
memory
used by all
other
processes


Linux Vulnerabilities
• Some common vulnerabilities in default Linux
installations (unpatched and unsecured) have
been:
o Buffer overflows
o Race conditions
o Abuse of programs run “setuid root”
o Denial of service (DoS)
o Web application vulnerabilities
o Rootkit attacks

© 2016 Pearson Education, Inc.,
Hoboken, NJ. All rights reserved.


Abuse of Programs Run
“setuid root”
A setuid root program is a root-owned program with its setuid
bit set --- a program that runs as root no matter who executes
it

If a setuid root program can be exploited or abused in some
way, then otherwise unprivileged users may be able to use
that program to wield unauthorized root privileges --- possibly
opening a root shell (a command-line session running with
root privileges)
Running setuid root is necessary for programs that need to be
run by unprivileged users yet must provide such users with
access to privileged functions --- for example, changing their
password, which requires changes to protected system files

A root-owned program should only have its setuid bit set if
absolutely necessary

© 2016 Pearson Education, Inc.,
Hoboken, NJ. All rights reserved.


Web Application
Vulnerabilities
This is a very broad category of vulnerabilities, many of which fall
into other categories in the list
While Web applications written in scripting languages such as PHP,
Perl, and Java may not be as prone to classic buffer overflows
they’re nonetheless prone to similar abuses of poor input-handling
Nowadays few Linux distributions ship with “enabled-by-default”
Web applications
However, many users install Web applications with known
vulnerabilities, or write custom Web applications having easily
identified and easily exploited flaws


© 2016 Pearson Education, Inc.,
Hoboken, NJ. All rights reserved.


×