LinuxCon 2010 presentation slides

1. Your First Guide to
”secure Linux”
August 12, 2010
Toshiharu Harada
haradats@nttdata.co.jp
NTT DATA CORPORATION

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.

3. Excuse me, Hey!
why you look so I just found a
happy? terrible
vulnerability!

4. Aren’t you having
fun? Deadly wrong,
everything is just
for you

5. Prologue
"Whenever people agree with me,
I always feel I must be wrong”
-- Oscar Wilde

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

7. What is “OS with enhanced security”?

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

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

10. • Tons of information on the net ...
• Open source implementations available ...
• Active and friendly community ...
What’s the missing link?

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

12. 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

13. This presentation is
intended to provide you the fundamental
concepts of
• what “secure OS” is
• why it has to be developed

14. 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)

15. “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)

16. Pros of “secure Linux”
• It can reduce the potential damages to your
Linux system when it gets exploited
• So, let’s start with “exploits”

17. Chap. 1
Exploits
"Give me a place to stand on, and
I will move the Earth.”
-- Archimedes

18. Wisdom from Microsoft Security
Response Center

19. 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”

20. 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
order 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.

21. 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.”

22. Exploits Demo
• Understanding the meaning of
“exploit” helps you to understand
what “secure OS” is
• Let’s see three examples

23. (1) ftp exploit

24. (2) samba exploit

25. (3) local exploit

26. 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

27. 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

28. Chap. 2
Linux
Security
“With great power, comes
great responsibility”
-- Peter Parker

29. 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

30. 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

31. What about Firewalls
and IDS?
Can they compensate DAC shortage?

32. 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

33. Click’N See

34. 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”?

35. Click’N See

36. 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

37. Chap. 3
MAC
"Although the world is full of
suffering, it is full also of the
overcoming of it.“
-- Helen Keller

38. 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

39. 1985

40. Amiga 1000 was
released in 1985

41. TCSEC
(TRUSTED COMPUTER SYSTEM EVALUATION CRITERIA)
Trusted Computer Systems
should have ...
Division A and “Verified Protection”
Division B and “Mandatory Protection”
Division C “Discretionary Protection”
Division D “Minimal Protection”

42. 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
objects 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)

43. DAC
read object
write
execute
user
group others
(self)

44. DAC
% chmod 600 my_file
read object
write
execute
user
group others
(self)

45. MAC
• MAC (Mandatory Access Control) can
improve the situation which DAC
cannot solve

46. MAC defined by TCSEC
• “The TCB shall enforce a mandatory access
control policy over all subjects and storage
objects 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.”

47. MAC
subject grant or reject object
A B
label for label for
A B

48. NSA SELinux FAQ
Security of Linux system depends ...
1. Unmodified Linux system
2. Linux system with MAC

49. Security of
“Unmodified Linux System”
se curity
privileged
applications
correctness of the
kernel

50. Security of
“Linux System with MAC”
security
security policy
correctness of the
kernel
MAC

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

52. 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)

53. Click’N See

54. 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

55. “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”)

56. 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

57. 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

58. 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

59. 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”

60. “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”)

61. “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

62. userspace
kernel

63. 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

64. 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

65. “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)

66. 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

67. References
Live as if you were to die tomorrow.
Learn as if you were to live forever.
-- Mahatma Gandhi

68. For Comprehensive Understanding
of 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.

69. Linux Kernel Security Wiki
Best place to find Linux kernel security
related projects

70. 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

71. Find the Code
Linux Cross Reference

72. 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

73. 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

74. RHEL Certifications

75. Other Topics

76. 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

77. Secure Embedded Linux
Google’s Android and Chromium OS are adding
unique modifications to improve security

78. Secure Embedded Linux

79. “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
other

80. “Cloud”
Commonly used virtualization library
“libvirt” has been incorporated the results
of “sVirt (secure virtualization)”

81. 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

82. “Loving can cost a lot, but not loving always
costs more.”
-- Merle Shain

83. Why not starting today?

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

85. Contact Information
My e-mail: haradats@gmail.com
I’m sharing slides at SlideShare as “haradats”
• Selected presentations of my project and
TOMOYO Linux and my own experiences

86. 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