Your First Guide to secure Linux August 12, 2010 Toshiharu Harada - - PowerPoint PPT Presentation

▶
your first guide to secure linux
SMART_READER_LITE
LIVE PREVIEW

Your First Guide to secure Linux August 12, 2010 Toshiharu Harada - - PowerPoint PPT Presentation

Mar 14, 2024 32 likes •873 views

Your First Guide to secure Linux August 12, 2010 Toshiharu Harada haradats@nttdata.co.jp NTT DATA CORPORATION Abstract There are two types of people in the world. Those who are security

slide-1
SLIDE 1

Your First Guide to ”secure Linux”

August 12, 2010 Toshiharu Harada haradats@nttdata.co.jp NTT DATA CORPORATION

slide-2
SLIDE 2

Abstract

There ¡are ¡two ¡types ¡of ¡people ¡in ¡the ¡world. ¡Those ¡who ¡are ¡ security ¡experts, ¡and ¡the ¡remainder ¡of ¡the ¡world. ¡In ¡most ¡cases, ¡ security ¡experts ¡are ¡willing ¡to ¡provide ¡technical ¡assistance ¡to ¡ people, ¡but ¡this ¡does ¡not ¡always ¡work ¡as ¡the ¡information ¡can ¡be ¡ highly ¡technical ¡and ¡confusing ¡if ¡you ¡are ¡not ¡comfortable ¡with ¡ the ¡fundamentals ¡of ¡Linux ¡security. Toshiharu ¡Harada, ¡Project ¡Manager ¡for ¡TOMOYO ¡Linux ¡at ¡NTT ¡ DATA ¡CORPORATION ¡will ¡share ¡the ¡fundamental ¡concepts ¡of ¡ "secure ¡Linux" ¡for ¡managers ¡and ¡end ¡users ¡who ¡have ¡little ¡or ¡no ¡ familiarity ¡with ¡security. ¡This ¡session ¡does ¡not ¡require ¡any ¡ special ¡skills ¡or ¡knowledge, ¡and ¡is ¡*not* ¡designed ¡for ¡security ¡ experts.

slide-3
SLIDE 3

Prologue

"Whenever people agree with me, I always feel I must be wrong”

  • - Oscar Wilde
slide-4
SLIDE 4

“secure Linux” is a Linux version of “OS with enhanced security”

slide-5
SLIDE 5

What is “OS with enhanced security”?

slide-6
SLIDE 6

You can Google it as always, but what you get will be much more than you want (and hard to understand)

slide-7
SLIDE 7

If you ask “security people” ... You’ll get the same results in 3D

slide-8
SLIDE 8
  • Tons of information on the net ...
  • Open source implementations available ...
  • Active and friendly community ...

What’s the missing link?

slide-9
SLIDE 9

Maybe the missing link is the “concept” of “secure Linux” So, here I am

slide-10
SLIDE 10

Who Am I?

  • Project manager of TOMOYO Linux, one of the

“secure Linux” extensions part of the upstream

  • When I launched TOMOYO project in 2003, I

started investing of the existing projects

  • Thanks to many people, TOMOYO has been

incorporated in the mainline Linux kernel

slide-11
SLIDE 11

This presentation is intended to provide you the fundamental concepts of

  • what “secure OS” is
  • why it has to be developed
slide-12
SLIDE 12

What You Get Understanding the underlying concepts of “secure Linux” should help you

  • to enlarge your administrative knowledge

and experience

  • to make a good decision on when and how

you need it

  • to protect your system (someday)
slide-13
SLIDE 13

“secure Linux” is

  • a name for Linux version of “secure OS

(operating system)”

  • Linux has three “secure Linux” extensions:

SELinux, SMACK and TOMOYO currently, and AppArmor (to be merged for 2.6.36)

slide-14
SLIDE 14

Pros of “secure Linux”

  • It can reduce the potential damages to your

Linux system when it gets exploited

  • So, let’s start with “exploits”
slide-15
SLIDE 15
  • Chap. 1

Exploits

"Give me a place to stand on, and I will move the Earth.”

  • - Archimedes
slide-16
SLIDE 16

Wisdom from Microsoft Security Response Center

slide-17
SLIDE 17

Law #1

“If a bad guy can persuade you to run his program on your computer, it’s not your computer anymore”

  • Actually, a bad guy can run his

program on your computer without persuading “you”

  • That’s what we call an “exploit”
slide-18
SLIDE 18

What is an “exploit”?

From Wikipedia (as of July 15th, 2010)

  • An exploit is a piece of software, a chunk of

data, or sequence of commands that take advantage of a bug, glitch or vulnerability in

  • rder to cause unintended or unanticipated

behavior to occur on computer software, hardware, or something electronic (usually computerised).

  • This frequently includes such things as gaining

control of a computer system or allowing privilege escalation or a denial of service attack.

slide-19
SLIDE 19

Bad luck aspect of computer science

From “10 Immutable Laws of Security by Microsoft” Law #1

  • “It’s an unfortunate fact of computer

science: when a computer program runs, it will do what it’s programmed to do, even if it’s programmed to be harmful.”

slide-20
SLIDE 20

Exploits Demo

  • Understanding the meaning of

“exploit” helps you to understand what “secure OS” is

  • Let’s see three examples
slide-21
SLIDE 21

(1) ftp exploit

slide-22
SLIDE 22

(2) samba exploit

slide-23
SLIDE 23

(3) local exploit

slide-24
SLIDE 24

Know Thy Enemy

  • Typical procedures of exploits
  • 1. Connect to a server pretending a normal

client

  • 2. Check to see if a server is a vulnerable one
  • 3. Cause “misbehavior” by buffer overflow

and other technique

  • Their goal is gaining the root privilege
slide-25
SLIDE 25

Chap.1 Summary

  • Exploits are based on vulnerabilities
  • Vulnerabilities are common and your

systems is exposed to many risks

  • Exploits aim to obtain root privilege of

your system in the most cases

slide-26
SLIDE 26
  • Chap. 2

Linux Security

“With great power, comes great responsibility”

  • - Peter Parker
slide-27
SLIDE 27

Reviewing Good Old Linux Security

  • Linux had got “security”, of course
  • it’s called Discretionary Access Control

(DAC, for short)

  • “Owners” (and root) can define access

permissions through “chmod” command

  • Any problem with that?
  • Yes, unfortunately
slide-28
SLIDE 28

Problem with DAC

  • Root user can violate DAC settings
  • DAC cannot help when ...
  • your server is exploited
  • a bad guy manages to login your server as

root

  • It’s useless against exploits
slide-29
SLIDE 29

What about Firewalls and IDS?

Can they compensate DAC shortage?

slide-30
SLIDE 30

Firewall and IDS

  • Firewall
  • Exploits pretend to be good clients and try

to connect through opened ports

  • IDS
  • IDS can’t recognize unknown/future

attacks and vulnerabilities

slide-31
SLIDE 31

Click’N See

slide-32
SLIDE 32

Buffer Overflow

  • We learned that DAC and other traditional

Linux security are not quite dependable

  • Suppose “buffer overflow” is a typical

approach of attacks, can we prevent them causing “buffer overflow”?

slide-33
SLIDE 33

Click’N See

slide-34
SLIDE 34

Buffer Overflow

  • What is it?
  • Intentionally cause overflow of “buffer” to

gain control and execute /bin/sh

  • How to protect?
  • Various tools and technologies have been

invented, but not guarantee safe

slide-35
SLIDE 35
  • Chap. 3

MAC

"Although the world is full of suffering, it is full also of the

  • vercoming of it.“
  • - Helen Keller
slide-36
SLIDE 36

Origins of secure OS

  • In ‘80s, research has been made in the

USA, to define evaluation criteria for trusted computer systems

  • DoD unveiled “Trusted Computer

Systems Evaluation Criteria” (TCSEC, aka “Orange Book”) in 1985

slide-37
SLIDE 37

1985

slide-38
SLIDE 38

Amiga 1000 was released in 1985

slide-39
SLIDE 39

TCSEC

(TRUSTED COMPUTER SYSTEM EVALUATION CRITERIA) “Discretionary Protection” and “Mandatory Protection” and “Verified Protection”

Trusted Computer Systems should have ... Division A Division B Division C Division D “Minimal Protection”

slide-40
SLIDE 40

DAC defined by TCSEC

  • “The TCB* shall define and control access

between named users and named objects in the ADP* system.”

  • “The enforcement mechanism shall allow

users to specify and control sharing of those

  • bjects by named individuals or defined

groups or both.”

  • TCB: Trusted Computing Base, ADP: automatic data processing

( you don’t have to remember these terms, I think)

slide-41
SLIDE 41

DAC

  • bject

user (self)

  • thers

group execute read write

slide-42
SLIDE 42

DAC

  • bject

user (self)

  • thers

group execute % chmod 600 my_file read write

slide-43
SLIDE 43

MAC

  • MAC (Mandatory Access Control) can

improve the situation which DAC cannot solve

slide-44
SLIDE 44

MAC defined by TCSEC

  • “The TCB shall enforce a mandatory access

control policy over all subjects and storage

  • bjects under its control.”
  • “These subjects and objects shall be assigned

sensitivity labels that are a combination of hierarchical classification levels and non- hierarchical categories, and the labels shall be used as the basis for mandatory access control decisions.”

slide-45
SLIDE 45

MAC

subject A

  • bject

B label for A label for B

grant or reject

slide-46
SLIDE 46

NSA SELinux FAQ

Security of Linux system depends ... 1.Unmodified Linux system 2.Linux system with MAC

slide-47
SLIDE 47

Security of “Unmodified Linux System”

security correctness of the kernel

privileged applications

slide-48
SLIDE 48

MAC

Security of “Linux System with MAC”

security correctness of the kernel security policy

slide-49
SLIDE 49

How MAC can help? (samba exploit vs. TOMOYO)

slide-50
SLIDE 50

Differences

Unchanged (Things you cannot change)

  • exploit has occurred
  • a bad guy obtained “root” shell without

logging in Changed (Things you can change with MAC)

  • some commands failed despite of “root”

privilege (MAC introduced a new layer of security)

slide-51
SLIDE 51

Click’N See

slide-52
SLIDE 52
  • Chap. 4

“Policy”

God, give us grace to accept with serenity the things that cannot be changed, Courage to change the things which should be changed, and the Wisdom to distinguish the one from the other.

  • - Reinhold Niebuhr
slide-53
SLIDE 53

“secure Linux” needs “policy”

  • MAC is an “instrument” to restrict invalid

accesses, not a “brain”

  • You (security admin) do instruct MAC

system about good and bad accesses by defining a “policy” (AppArmor calls it “profile”)

slide-54
SLIDE 54

Importance of “policy”

The goal is very simple

  • Grant access if it’s correct (or needed)
  • Reject everything else

If you make mistakes in your policy

  • system might fail to work properly
  • system might not be protected
slide-55
SLIDE 55

The Serenity Prayer

O God, give us grace to accept with serenity the things that cannot be changed, Courage to change the things which should be changed, and the Wisdom to distinguish the one from the other

slide-56
SLIDE 56

The Security Prayer

(with my deepest respects for Reinhold Niebuhr)

O God, give us grace to accept with serenity the things that are needed, Courage to reject the things which are not necessary, and the Wisdom to distinguish the one from the other

slide-57
SLIDE 57

Where to find the wisdom?

SELinux has a “reference policy”

  • “that embodies the built-up knowledge over

the years about what accesses are in fact required for a large body of software”

  • novice users can start with “Boolean” and

power users can maintain their own foundation TOMOYO and SMACK

  • “Do it yourself”
slide-58
SLIDE 58

“Domain”

  • No program is always good or always bad
  • Therefore, security policies are the set of

security contexts (conditions)

  • SELinux and TOMOYO call them

“domains” (AppArmor call them “profiles”)

slide-59
SLIDE 59

“Domain”

“Granularity” of MAC policy is determined by two factors

  • “domain” granularity
  • access control granularity for each

domain Both live in the kernel space, not in the userspace

slide-60
SLIDE 60

kernel userspace

slide-61
SLIDE 61

Managing Policy

What and When

  • Give permissions only when they are needed
  • Delete permissions if they turned out to be

unnecessary How

  • Carefully monitor the logs
slide-62
SLIDE 62

Managing Policy

Cautions

  • a policy “error” is detected/defined when a

access occurs but its definition is missing among policy rules

  • you can add such an error definition to the

policy, in fact transforming it into policy rule, so that the same error will not occur anymore

  • if you repeat this step thoughtlessly, you will

lose control

slide-63
SLIDE 63

“Policy Auto Learning”

What is it?

  • Feature available with AppArmor and

TOMOYO How it works?

  • Observing executions of system call
  • Transform results into the policy rule (like

audit2allow does for SELinux)

slide-64
SLIDE 64

Results of policy auto learning

  • can never be perfect
  • has no logics
  • should be considered as a starting point

Auto learning feature can be used as an analysis tool or an educational tool

slide-65
SLIDE 65

References

Live as if you were to die tomorrow. Learn as if you were to live forever.

  • - Mahatma Gandhi
slide-66
SLIDE 66

For Comprehensive Understanding

  • f Linux Security

Ideal reference by James Morris, who is the Linux kernel security subsystem maintainer; author of the kernel cryptographic API; and a leading contributor to the SELinux, Linux Security Module, Netfilter and IPsec projects.

slide-67
SLIDE 67

Linux Kernel Security Wiki

Best place to find Linux kernel security related projects

slide-68
SLIDE 68

To Know Your Enemy

  • “Apache.org services attacked” (April 13, 2010)

http://lwn.net/Articles/383260/

  • “Changes to LoCo Server Policy” (August 11, 2007)

https://lists.ubuntu.com/archives/loco-contacts/ 2007-August/001510.html

  • “Debian server compromise” (July 12, 2006) http://

www.debian-administration.org/articles/417

slide-69
SLIDE 69

Find the Code

Linux Cross Reference

slide-70
SLIDE 70

TCSEC to ISO/IEC 15408

  • TCSEC has expired and the current standard

is ISO/IEC 15408

  • Functional requirements have been

described as “protection profile”

  • LSPP (Labeled Security Protection Profile)

succeeds MAC in TCSEC

slide-71
SLIDE 71

Standards

  • National Security Institute -

5200.28-STD Trusted Computer System Evaluation Criteria

  • ISO/IEC 15408
  • CAPP: “Controlled Access”

protection profile

  • LSPP: “Labeled Security”

protection profile

slide-72
SLIDE 72

RHEL Certifications

slide-73
SLIDE 73

Other Topics

slide-74
SLIDE 74

Secure Embedded Linux

Characteristics of embedded devices

  • Dedicated for usages and built with minimum

resources

  • Mass production affects cost (recall for

millions, for instance)

  • Network/HD/Updates might not always be

available Linux has been spreading for embedded devices

slide-75
SLIDE 75

Secure Embedded Linux

Google’s Android and Chromium OS are adding unique modifications to improve security

slide-76
SLIDE 76

Secure Embedded Linux

slide-77
SLIDE 77

“Cloud”

  • Guest OS runs as a process from host OS /

hypervisor

  • Internal activities of guest OS are

translated, so host OS can hardly monitor and confine them

  • Guest OS share the NIC, HD and other

devices, so physically reachable each

  • ther
slide-78
SLIDE 78

“Cloud”

Commonly used virtualization library “libvirt” has been incorporated the results

  • f “sVirt (secure virtualization)”
slide-79
SLIDE 79

Congratulations

  • You’ve just learned the most difficult part of

Linux security, “understanding the concept”

  • Everything else is waiting for you to begin
  • If you understand “secure Linux”, you will

find it as an invaluable tool

slide-80
SLIDE 80

“Loving can cost a lot, but not loving always costs more.”

  • - Merle Shain
slide-81
SLIDE 81

Why not starting today?

slide-82
SLIDE 82

The Serenity Prayer by Reinhold Niebuhr (1892-1971) God, give us grace to accept with serenity the things that cannot be changed, Courage to change the things which should be changed, and the Wisdom to distinguish the one from the other. Living one day at a time, Enjoying one moment at a time, Accepting hardship as a pathway to peace, Taking, as Jesus did, This sinful world as it is, Not as I would have it, Trusting that You will make all things right, If I surrender to Your will, So that I may be reasonably happy in this life, And supremely happy with you forever in the next. Amen

slide-83
SLIDE 83

Contact Information

I would like to make these slides useful for future readers, so please send your comments and corrections to haradats@gmail.com Open source is a mutual benefit society, so I’m sharing my own experiences as TOMOYO Linux project manager as well as selected technical slides

slide-84
SLIDE 84

The latest version of these slides can be found at SlideShare Acknowledgements Special thanks to Giuseppe La Tona, Tetsuo Handa for reviewing and Stephen Smalley for correcting SELinux related information Trademarks Linux is a registered trademark of Linus Torvalds in the United States and other countries TOMOYO is a registered trademark of NTT DATA CORPORATION in Japan