Linux/Unix安全编程指南：设计与实践

需积分: 1 57 浏览量更新于2024-07-22 收藏 864KB PDF 举报

《Secure-Programs-HOWTO》是一本专为Linux和Unix环境下的安全编程提供实用指南的书籍，作者是David A. Wheeler。该版本为第三版第五十次修订，发布日期为2004年8月22日。这本书的核心目标是为开发者提供一套全面的设计和实现原则，以确保编写出能在这些操作系统上运行的安全程序。这些程序涵盖了远程数据查看器、Web应用（包括CGI脚本）、网络服务器以及具有setuid/setgid权限的程序。书中特别关注了对C、C++、Java、Perl、PHP、Python、Tcl和Ada95等常用编程语言的指导，每种语言都有针对性的安全编码建议。对于寻求最新资料的读者，作者建议访问http://www.dwheeler.com/secure-programs，获取最新的更新和资源。版权方面，这本书受GNU Free Documentation License (GFDL) 版1.1或其后续版本的保护。根据此许可证，用户可以自由复制、分发和修改本书，但需遵循特定条件，包括保留作者信息、“关于作者”部分不能被更改，以及封面和封底的文字不得改动。版权信息和GFDL的具体条款在“GNU Free Documentation License”章节中详尽说明，这也是本书的重要组成部分。《Secure-Programs-HOWTO》旨在帮助开发人员在复杂且潜在威胁的Linux和Unix环境中构建稳健的应用程序，从而提高系统的安全性，减少漏洞和攻击的风险。阅读这本书，开发者不仅能够学习到如何编写抵御恶意代码、保护用户隐私以及防止数据泄露的策略，还能了解到如何在开发过程中遵循最佳实践，确保程序在高风险的计算环境中稳定运行。

Chapter 2. Background

2.1.2. Free Software Foundation

In 1984 Richard Stallman’s Free Software Foundation (FSF) began the GNU project, a project to create a

free version of the Unix operating system. By free, Stallman meant software that could be freely used,

read, modiﬁed, and redistributed. The FSF successfully built a vast number of useful components,

including a C compiler (gcc), an impressive text editor (emacs), and a host of fundamental tools.

However, in the 1990’s the FSF was having trouble developing the operating system kernel [FSF 1998];

without a kernel their dream of a completely free operating system would not be realized.

2.1.3. Linux

In 1991 Linus Torvalds began developing an operating system kernel, which he named “Linux”

[Torvalds 1999]. This kernel could be combined with the FSF material and other components (in

particular some of the BSD components and MIT’s X-windows software) to produce a freely-modiﬁable

and very useful operating system. This book will term the kernel itself the “Linux kernel” and an entire

combination as “Linux”. Note that many use the term “GNU/Linux” instead for this combination.

In the Linux community, different organizations have combined the available components differently.

Each combination is called a “distribution”, and the organizations that develop distributions are called

“distributors”. Common distributions include Red Hat, Mandrake, SuSE, Caldera, Corel, and Debian.

There are differences between the various distributions, but all distributions are based on the same

foundation: the Linux kernel and the GNU glibc libraries. Since both are covered by “copyleft” style

licenses, changes to these foundations generally must be made available to all, a unifying force between

the Linux distributions at their foundation that does not exist between the BSD and AT&T-derived Unix

systems. This book is not speciﬁc to any Linux distribution; when it discusses Linux it presumes Linux

kernel version 2.2 or greater and the C library glibc 2.1 or greater, valid assumptions for essentially all

current major Linux distributions.

2.1.4. Open Source / Free Software

Increased interest in software that is freely shared has made it increasingly necessary to deﬁne and

explain it. A widely used term is “open source software”, which is further deﬁned in [OSI 1999]. Eric

Raymond [1997, 1998] wrote several seminal articles examining its various development processes.

Another widely-used term is “free software”, where the “free” is short for “freedom”: the usual

explanation is “free speech, not free beer.” Neither phrase is perfect. The term “free software” is often

confused with programs whose executables are given away at no charge, but whose source code cannot

be viewed, modiﬁed, or redistributed. Conversely, the term “open source” is sometime (ab)used to mean

software whose source code is visible, but for which there are limitations on use, modiﬁcation, or

redistribution. This book uses the term “open source” for its usual meaning, that is, software which has

its source code freely available for use, viewing, modiﬁcation, and redistribution; a more detailed

deﬁnition is contained in the Open Source Deﬁnition. In some cases, a difference in motive is suggested;

those preferring the term “free software” wish to strongly emphasize the need for freedom, while those

using the term may have other motives (e.g., higher reliability) or simply wish to appear less strident. For

information on this deﬁnition of free software, and the motivations behind it, can be found at

http://www.fsf.org.

Those interested in reading advocacy pieces for open source software and free software should see

http://www.opensource.org and http://www.fsf.org. There are other documents which examine such

Chapter 2. Background

software, for example, Miller [1995] found that the open source software were noticeably more reliable

than proprietary software (using their measurement technique, which measured resistance to crashing

due to random input).

2.1.5. Comparing Linux and Unix

This book uses the term “Unix-like” to describe systems intentionally like Unix. In particular, the term

“Unix-like” includes all major Unix variants and Linux distributions. Note that many people simply use

the term “Unix” to describe these systems instead. Originally, the term “Unix” meant a particular product

developed by AT&T. Today, the Open Group owns the Unix trademark, and it deﬁnes Unix as “the

worldwide Single UNIX Speciﬁcation”.

Linux is not derived from Unix source code, but its interfaces are intentionally like Unix. Therefore,

Unix lessons learned generally apply to both, including information on security. Most of the information

in this book applies to any Unix-like system. Linux-speciﬁc information has been intentionally added to

enable those using Linux to take advantage of Linux’s capabilities.

Unix-like systems share a number of security mechanisms, though there are subtle differences and not all

systems have all mechanisms available. All include user and group ids (uids and gids) for each process

and a ﬁlesystem with read, write, and execute permissions (for user, group, and other). See Thompson

[1974] and Bach [1986] for general information on Unix systems, including their basic security

mechanisms. Chapter 3 summarizes key security features of Unix and Linux.

2.2. Security Principles

There are many general security principles which you should be familiar with; one good place for

general information on information security is the Information Assurance Technical Framework (IATF)

[NSA 2000]. NIST has identiﬁed high-level “generally accepted principles and practices” [Swanson

1996]. You could also look at a general textbook on computer security, such as [Pﬂeeger 1997]. NIST

Special Publication 800-27 describes a number of good engineering principles (although, since they’re

abstract, they’re insufﬁcient for actually building secure programs - hence this book); you can get a copy

at http://csrc.nist.gov/publications/nistpubs/800-27/sp800-27.pdf.A few security principles are

summarized here.

Often computer security objectives (or goals) are described in terms of three overall objectives:

• Conﬁdentiality (also known as secrecy), meaning that the computing system’s assets can be read only

by authorized parties.

• Integrity, meaning that the assets can only be modiﬁed or deleted by authorized parties in authorized

ways.

• Availability, meaning that the assets are accessible to the authorized parties in a timely manner (as

determined by the systems requirements). The failure to meet this goal is called a denial of service.

Some people deﬁne additional major security objectives, while others lump those additional goals as

special cases of these three. For example, some separately identify non-repudiation as an objective; this

is the ability to “prove” that a sender sent or receiver received a message (or both), even if the sender or

receiver wishes to deny it later. Privacy is sometimes addressed separately from conﬁdentiality; some

Chapter 2. Background

deﬁne this as protecting the conﬁdentiality of a user (e.g., their identity) instead of the data. Most

objectives require identiﬁcation and authentication, which is sometimes listed as a separate objective.

Often auditing (also called accountability) is identiﬁed as a desirable security objective. Sometimes

“access control” and “authenticity” are listed separately as well. For example, The U.S. Department of

Defense (DoD), in DoD directive 3600.1 deﬁnes “information assurance” as “information operations

(IO) that protect and defend information and information systems by ensuring their availability, integrity,

authentication, conﬁdentiality, and nonrepudiation. This includes providing for restoration of

information systems by incorporating protection, detection, and reaction capabilities.”

In any case, it is important to identify your program’s overall security objectives, no matter how you

group them together, so that you’ll know when you’ve met them.

Sometimes these objectives are a response to a known set of threats, and sometimes some of these

objectives are required by law. For example, for U.S. banks and other ﬁnancial institutions, there’s a new

privacy law called the “Gramm-Leach-Bliley” (GLB) Act. This law mandates disclosure of personal

information shared and means of securing that data, requires disclosure of personal information that will

be shared with third parties, and directs institutions to give customers a chance to opt out of data sharing.

[Jones 2000]

There is sometimes conﬂict between security and some other general system/software engineering

principles. Security can sometimes interfere with “ease of use”, for example, installing a secure

conﬁguration may take more effort than a “trivial” installation that works but is insecure. Often, this

apparent conﬂict can be resolved, for example, by re-thinking a problem it’s often possible to make a

secure system also easy to use. There’s also sometimes a conﬂict between security and abstraction

(information hiding); for example, some high-level library routines may be implemented securely or not,

but their speciﬁcations won’t tell you. In the end, if your application must be secure, you must do things

yourself if you can’t be sure otherwise - yes, the library should be ﬁxed, but it’s your users who will be

hurt by your poor choice of library routines.

A good general security principle is “defense in depth”; you should have numerous defense mechanisms

(“layers”) in place, designed so that an attacker has to defeat multiple mechanisms to perform a

successful attack.

For general principles on how to design secure programs, see Section 7.1.

2.3. Why do Programmers Write Insecure Code?

Many programmers don’t intend to write insecure code - but do anyway. Here are a number of purported

reasons for this. Most of these were collected and summarized by Aleph One on Bugtraq (in a posting on

December 17, 1998):

• There is no curriculum that addresses computer security in most schools. Even when there is a

computer security curriculum, they often don’t discuss how to write secure programs as a whole.

Many such curriculum only study certain areas such as cryptography or protocols. These are

important, but they often fail to discuss common real-world issues such as buffer overﬂows, string

formatting, and input checking. I believe this is one of the most important problems; even those

programmers who go through colleges and universities are very unlikely to learn how to write secure

programs, yet we depend on those very people to write secure programs.

Chapter 2. Background

• Programming books/classes do not teach secure/safe programming techniques. Indeed, until recently

there were no books on how to write secure programs at all (this book is one of those few).

• No one uses formal veriﬁcation methods.

• C is an unsafe language, and the standard C library string functions are unsafe. This is particularly

important because C is so widely used - the “simple” ways of using C permit dangerous exploits.

• Programmers do not think “multi-user.”

• Programmers are human, and humans are lazy. Thus, programmers will often use the “easy” approach

instead of a secure approach - and once it works, they often fail to ﬁx it later.

• Most programmers are simply not good programmers.

• Most programmers are not security people; they simply don’t often think like an attacker does.

• Most security people are not programmers. This was a statement made by some Bugtraq contributors,

but it’s not clear that this claim is really true.

• Most computer security models are terrible.

• There is lots of “broken” legacy software. Fixing this software (to remove security faults or to make it

work with more restrictive security policies) is difﬁcult.

• Consumers don’t care about security. (Personally, I have hope that consumers are beginning to care

about security; a computer system that is constantly exploited is neither useful nor user-friendly. Also,

many consumers are unaware that there’s even a problem, assume that it can’t happen to them, or think

that that things cannot be made better.)

• Security costs extra development time.

• Security costs in terms of additional testing (red teams, etc.).

2.4. Is Open Source Good for Security?

There’s been a lot of debate by security practitioners about the impact of open source approaches on

security. One of the key issues is that open source exposes the source code to examination by everyone,

both the attackers and defenders, and reasonable people disagree about the ultimate impact of this

situation. (Note - you can get the latest version of this essay by going to the main website for this book,

http://www.dwheeler.com/secure-programs.

2.4.1. View of Various Experts

First, let’s exampine what security experts have to say.

Bruce Schneier is a well-known expert on computer security and cryptography. He argues that smart

engineers should “demand open source code for anything related to security” [Schneier 1999], and he

also discusses some of the preconditions which must be met to make open source software secure.

Vincent Rijmen, a developer of the winning Advanced Encryption Standard (AES) encryption algorithm,

believes that the open source nature of Linux provides a superior vehicle to making security

vulnerabilities easier to spot and ﬁx, “Not only because more people can look at it, but, more

Chapter 2. Background

importantly, because the model forces people to write more clear code, and to adhere to standards. This

in turn facilitates security review” [Rijmen 2000].

Elias Levy (Aleph1) is the former moderator of one of the most popular security discussion groups -

Bugtraq. He discusses some of the problems in making open source software secure in his article "Is

Open Source Really More Secure than Closed?". His summary is:

So does all this mean Open Source Software is no better than closed source software when it comes to security

vulnerabilities? No. Open Source Software certainly does have the potential to be more secure than its closed

source counterpart. But make no mistake, simply being open source is no guarantee of security.

Whitﬁeld Difﬁe is the co-inventor of public-key cryptography (the basis of all Internet security) and chief

security ofﬁcer and senior staff engineer at Sun Microsystems. In his 2003 article Risky business:

Keeping security a secret, he argues that proprietary vendor’s claims that their software is more secure

because it’s secret is nonsense. He identiﬁes and then counters two main claims made by proprietary

vendors: (1) that release of code beneﬁts attackers more than anyone else because a lot of hostile eyes

can also look at open-source code, and that (2) a few expert eyes are better than several random ones. He

ﬁrst notes that while giving programmers access to a piece of software doesn’t guarantee they will study

it carefully, there is a group of programmers who can be expected to care deeply: Those who either use

the software personally or work for an enterprise that depends on it. "In fact, auditing the programs on

which an enterprise depends for its own security is a natural function of the enterprise’s own

information-security organization." He then counters the second argument, noting that "As for the notion

that open source’s usefulness to opponents outweighs the advantages to users, that argument ﬂies in the

face of one of the most important principles in security: A secret that cannot be readily changed should

be regarded as a vulnerability." He closes noting that

"It’s simply unrealistic to depend on secrecy for security in computer software. You may be able to keep the

exact workings of the program out of general circulation, but can you prevent the code from being

reverse-engineered by serious opponents? Probably not."

John Viega’s article "The Myth of Open Source Security" also discusses issues, and summarizes things

this way:

Open source software projects can be more secure than closed source projects. However, the very things that

can make open source programs secure -- the availability of the source code, and the fact that large numbers of

users are available to look for and ﬁx security holes -- can also lull people into a false sense of security.

Michael H. Warﬁeld’s "Musings on open source security" is very positive about the impact of open

source software on security. In contrast, Fred Schneider doesn’t believe that open source helps security,

saying “there is no reason to believe that the many eyes inspecting (open) source code would be

successful in identifying bugs that allow system security to be compromised” and claiming that “bugs in

the code are not the dominant means of attack” [Schneider 2000]. He also claims that open source rules

out control of the construction process, though in practice there is such control - all major open source

programs have one or a few ofﬁcial versions with “owners” with reputations at stake. Peter G. Neumann

discusses “open-box” software (in which source code is available, possibly only under certain

conditions), saying “Will open-box software really improve system security? My answer is not by itself,

although the potential is considerable” [Neumann 2000]. TruSecure Corporation, under sponsorship by

Red Hat (an open source company), has developed a paper on why they believe open source is more

剩余197页未读，继续阅读

SjtuBoyceField

粉丝: 0
资源: 7

Linux/Unix安全编程指南：设计与实践

Secure Programming for Linux and Unix HOWTO.rtf

Secure Programs HOWTO

hands-network-programming-c-optimized.rar

Java - A Beginner’s Guide - Sixth Edition - Herbert Schildt

Software Development, Design and Coding-2nd Edition-Apress(2017).pdf

Essential C# 5.0-Englis

软件测试相关论文-英文原文82篇

Wiley-Schneier on Security(2008).pdf

How to Forward Local Ports Using MobaXterm

How to Manage and Use Remote Desktop with MobaXterm

最新资源