Introduction to Unix Security for Security Practitioners

Total Page:16

File Type:pdf, Size:1020Kb

Introduction to Unix Security for Security Practitioners 84-01-19 DATA SECURITY MANAGEMENT INTRODUCTION TO UNIX SECURITY FOR SECURITY PRACTITIONERS Jeffery J. Lowder INSIDE Operating System Security Services; Identification and Authentication; Access Control; Availability and Integrity; Audit; Security Facilities for Users; Vulnerabilities in Traditional UNIX; TCP Wrappers; Login or Warning Banners In an age of increasingly sophisticated security tools (e.g., firewalls, vir- tual private networks, intrusion detection systems, etc.), many people do not consider operating system security a very sexy topic. Indeed, given that the UNIX operating system was originally developed in 1969 and that multiple full-length books have been written on protecting UNIX machines, one might be tempted to dismiss the entire topic as “old hat.” Nevertheless, operating system security is a crucial component of an overall security program. In the words of Anup Ghosh, the operating sys- tem is “the foundation for any software that runs on a machine,” and this is just as true in the era of E-commerce as it was in the past. Thus, secu- rity practitioners who are even indirectly responsible for the protection of UNIX machines need to have at least a basic understanding of UNIX security. This article attempts to address that need by providing an over- view of security services common to all flavors of UNIX; security mech- anisms available in trusted UNIX are beyond the scope of this article (but see Exhibit 1). OPERATING SYSTEM SECURITY SERVICES PAYOFF IDEA Summers1 (1997) lists the following Operating system security is a crucial component security services that operating sys- of an overall security program. Thus, security tems in general can provide: practitioners who are even indirectly responsible for the protection of UNIX machines need to have at least a basic understanding of UNIX security. 1. Identification and authentica- This article addresses that need by providing an tion: A secure operating system overview of security services common to all fla- vors of UNIX. Auerbach Publications © 2000 CRC Press LLC EXHIBIT 1 — Versions of Trusted or Secure UNIX A1 (Verified Design) No operating systems have been evaluated in class A1 B3 (Security Domains) Wang Government Services, Inc., XTS-300 STOP 4.4.2 B2 (Structured Protection) Trusted Information Systems, Inc. Trusted XENIX 4.0 B1 (Labeled Security Protection) Digital Equipment Corporation ULTRIX MLS+ Version 2.1 on VAX Station 3100 Hewlett Packard Corporation HP-UX BLS Release 9.09+ Silicon Graphics Inc. Trusted IRIX/B Release 4.0.5EPL C2 (Controlled Access Protection) No UNIX operating systems have been evaluated in class C2 C1 (Discretionary Access Protection) Products are no longer evaluated at this class D1 (Minimal Protection) No operating systems have been evaluated in class D1 Note: Various versions of UNIX have been evaluated by the U.S. Government’s National Security Agency (NSA) according to the Trusted Computer System Evaluation Criteria. (By way of comparison, Microsoft Corporation’s Windows NT Worksta- tion and Windows NT Server, version 4.0, have both been evaluated at class C2.) The above chart is taken from the NSA’s Evaluated Product List. must be able to distinguish between different users (identification); it also needs some assurance that users are who they say they are (au- thentication). Identification and authentication are crucial to the oth- er operating system security services. There are typically three ways to authenticate users: something the user knows (e.g., a password), something the user has (e.g., a smart card), or something the user is (e.g., a retinal pattern). Passwords are by far the most common au- thentication method; this method is also extremely vulnerable to compromise. Passwords can be null, easily guessed, cracked, written down and then discovered, or “sniffed.” 2. Access control: An operating system is responsible for providing log- ical access control through the use of subjects, objects, access rights, and access validation. A subject includes a userID, password, group memberships, privileges, etc. for each user. Object security informa- tion includes the owner, group, access restrictions, etc. Basic access rights include read, write, and execute. Finally, an operating system evaluates an access request (consisting of a subject, an object, and the requested access) according to access validation rules. 3. Availability and integrity: Does the system start up in a secure fash- ion? Does the system behave according to expectations during an at- tack? Is the data on the system internally consistent? Does the data correspond with the real-world entities that it represents? Auerbach Publications © 2000 CRC Press LLC 4. Audit: An audit trail contains a chronological record of events. Audit trails can be useful as a deterrent; they are even more useful in inves- tigating incidents (e.g., Who did it? How?). Audit trails have even been used as legal evidence in criminal trials. However, for an audit trail to be useful in any of these contexts, the operating system must record all security-relevant events, protect the confidentiality and in- tegrity of the audit trail, and ensure that the data is available in a timely manner. 5. Security facilities for users: Non-privileged users need some method for granting rights to their files and changing their passwords. Privi- leged users need additional facilities, including the ability to lock ac- counts, gain access to other users’ files, configure auditing options, change ownership of files, change users’ memberships in groups, etc. The remainder of this article explores how these services are imple- mented in the UNIX family of operating systems. IDENTIFICATION AND AUTHENTICATION UNIX identifies users according to usernames and authenticates them with passwords. In many implementations of UNIX, both usernames and passwords are limited to eight characters. As a security measure, UNIX does not store passwords in plaintext. Instead, it stores the password as ciphertext, using a modified Digital Encryption Standard (DES) algorithm (crypt) for encryption. The encrypted password, along with other perti- nent account information (see Exhibit 2), is stored in the /etc/passwd file according to the following format: username:encrypted password:UserID:GroupID:user’s full name:home directory:login shell Unfortunately, the /etc/passwd file is world-readable, which can place standard, “out-of-the-box” configurations of UNIX at risk for a brute-force password-guessing attack by anyone with system access. Given enough computing resources and readily available tools like Alec Muffet’s crack EXHIBIT 2 — Sample /etc/passwd Entries keith::1001:15:Keith Smith:/usr/keith:/bin/csh greg:Qf@14pL1aqzqB:Greg Jones:/usr/greg/:/bin/csh cathy:*:1003:15:Cathy Jones:/usr/cathy:/bin/csh Note: In this example, user keith has no password, user greg has an encrypted password, and user cathy has a shadowed password. Auerbach Publications © 2000 CRC Press LLC utility, an attacker can eventually guess every password on the system. In light of this vulnerability, all current implementations of UNIX now pro- vide support for so-called “shadow” passwords. The basic idea is to store the encrypted passwords in a separate file (/etc/shadow to be exact) that is only readable by the privileged “root” account. Also, although vanilla UNIX does not provide support for proactive password checking, add-on tools are available. Finally, password aging is not part of standard UNIX but is supported by many proprietary implementations. UserIDs (UIDs) are typically 16-bit integers, meaning that they can have any value between 0 and 65,535. The operating system uses UIDs, not usernames, to track users. Thus, it is entirely possible in UNIX for two or more usernames to share the same UID. In general, it is a bad idea to give two usernames the same UID. Also, certain UIDs are reserved. (For example, any username with an UID of zero is considered root by the operating system.) Finally, UNIX requires that certain programs like /bin/passwd (used by users to change their passwords) and /bin/login (executed when a user initiates a login sequence) run as root; however, users should not be able to arbitrarily gain root permissions on the sys- tem. UNIX solves this problem by allowing certain programs to run un- der the permissions of another UID. Such programs are called Set UserID (SUID) programs. Of course, such programs can also be risky: if attackers are able to interrupt an SUID program, they may be able to gain root ac- cess and ensure that they are able to regain such access in the future. Group IDs (GIDs) are also typically 16-bit integers. The GID listed in a user’s entry in /etc/passwd is that user’s primary GID; however, in some versions of UNIX, a user can belong to more than one group. A complete listing of all groups, including name, GID, and members (users), can be found in the file /etc/group. Once a user successfully logs in, UNIX executes the global file /etc/profile along with the .profile file in the user’s home directory using the user’s shell specified in /etc/passwd. If the permissions on these files are not restricted properly, an attacker could modify these files and cause unauthorized commands to be executed each time the user logs in. UNIX also updates the file /usr/adm/lastlog, which stores the date and time of the latest login for each account. This information can be obtained via the finger command and creates another vulnerability: systems with the finger command enabled may unwittingly provide attackers with useful information in planning an attack. ACCESS CONTROL Standard UNIX systems prevent the unauthorized use of system resourc- es (e.g., files, memory, devices, etc.) by promoting discretionary access control. Permissions are divided into three categories: owner, group, and other. However, privileged accounts can bypass this access control. UNIX Auerbach Publications © 2000 CRC Press LLC treats all system resources consistently by making no distinction between files, memory, and devices; all resources are treated as files for access control purposes.
Recommended publications
  • Administering Unidata on UNIX Platforms
    C:\Program Files\Adobe\FrameMaker8\UniData 7.2\7.2rebranded\ADMINUNIX\ADMINUNIXTITLE.fm March 5, 2010 1:34 pm Beta Beta Beta Beta Beta Beta Beta Beta Beta Beta Beta Beta Beta Beta Beta Beta UniData Administering UniData on UNIX Platforms UDT-720-ADMU-1 C:\Program Files\Adobe\FrameMaker8\UniData 7.2\7.2rebranded\ADMINUNIX\ADMINUNIXTITLE.fm March 5, 2010 1:34 pm Beta Beta Beta Beta Beta Beta Beta Beta Beta Beta Beta Beta Beta Notices Edition Publication date: July, 2008 Book number: UDT-720-ADMU-1 Product version: UniData 7.2 Copyright © Rocket Software, Inc. 1988-2010. All Rights Reserved. Trademarks The following trademarks appear in this publication: Trademark Trademark Owner Rocket Software™ Rocket Software, Inc. Dynamic Connect® Rocket Software, Inc. RedBack® Rocket Software, Inc. SystemBuilder™ Rocket Software, Inc. UniData® Rocket Software, Inc. UniVerse™ Rocket Software, Inc. U2™ Rocket Software, Inc. U2.NET™ Rocket Software, Inc. U2 Web Development Environment™ Rocket Software, Inc. wIntegrate® Rocket Software, Inc. Microsoft® .NET Microsoft Corporation Microsoft® Office Excel®, Outlook®, Word Microsoft Corporation Windows® Microsoft Corporation Windows® 7 Microsoft Corporation Windows Vista® Microsoft Corporation Java™ and all Java-based trademarks and logos Sun Microsystems, Inc. UNIX® X/Open Company Limited ii SB/XA Getting Started The above trademarks are property of the specified companies in the United States, other countries, or both. All other products or services mentioned in this document may be covered by the trademarks, service marks, or product names as designated by the companies who own or market them. License agreement This software and the associated documentation are proprietary and confidential to Rocket Software, Inc., are furnished under license, and may be used and copied only in accordance with the terms of such license and with the inclusion of the copyright notice.
    [Show full text]
  • Types and Programming Languages by Benjamin C
    < Free Open Study > . .Types and Programming Languages by Benjamin C. Pierce ISBN:0262162091 The MIT Press © 2002 (623 pages) This thorough type-systems reference examines theory, pragmatics, implementation, and more Table of Contents Types and Programming Languages Preface Chapter 1 - Introduction Chapter 2 - Mathematical Preliminaries Part I - Untyped Systems Chapter 3 - Untyped Arithmetic Expressions Chapter 4 - An ML Implementation of Arithmetic Expressions Chapter 5 - The Untyped Lambda-Calculus Chapter 6 - Nameless Representation of Terms Chapter 7 - An ML Implementation of the Lambda-Calculus Part II - Simple Types Chapter 8 - Typed Arithmetic Expressions Chapter 9 - Simply Typed Lambda-Calculus Chapter 10 - An ML Implementation of Simple Types Chapter 11 - Simple Extensions Chapter 12 - Normalization Chapter 13 - References Chapter 14 - Exceptions Part III - Subtyping Chapter 15 - Subtyping Chapter 16 - Metatheory of Subtyping Chapter 17 - An ML Implementation of Subtyping Chapter 18 - Case Study: Imperative Objects Chapter 19 - Case Study: Featherweight Java Part IV - Recursive Types Chapter 20 - Recursive Types Chapter 21 - Metatheory of Recursive Types Part V - Polymorphism Chapter 22 - Type Reconstruction Chapter 23 - Universal Types Chapter 24 - Existential Types Chapter 25 - An ML Implementation of System F Chapter 26 - Bounded Quantification Chapter 27 - Case Study: Imperative Objects, Redux Chapter 28 - Metatheory of Bounded Quantification Part VI - Higher-Order Systems Chapter 29 - Type Operators and Kinding Chapter 30 - Higher-Order Polymorphism Chapter 31 - Higher-Order Subtyping Chapter 32 - Case Study: Purely Functional Objects Part VII - Appendices Appendix A - Solutions to Selected Exercises Appendix B - Notational Conventions References Index List of Figures < Free Open Study > < Free Open Study > Back Cover A type system is a syntactic method for automatically checking the absence of certain erroneous behaviors by classifying program phrases according to the kinds of values they compute.
    [Show full text]
  • UNIX Workshop Series: Quick-Start Objectives
    Part I UNIX Workshop Series: Quick-Start Objectives Overview – Connecting with ssh Command Window Anatomy Command Structure Command Examples Getting Help Files and Directories Wildcards, Redirection and Pipe Create and edit files Overview Connecting with ssh Open a Terminal program Mac: Applications > Utilities > Terminal ssh –Y [email protected] Linux: In local shell ssh –Y [email protected] Windows: Start Xming and PuTTY Create a saved session for the remote host name centos.css.udel.edu using username Connecting with ssh First time you connect Unix Basics Multi-user Case-sensitive Bash shell, command-line Commands Command Window Anatomy Title bar Click in the title bar to bring the window to the front and make it active. Command Window Anatomy Login banner Appears as the first line of a login shell. Command Window Anatomy Prompts Appears at the beginning of a line and usually ends in $. Command Window Anatomy Command input Place to type commands, which may have options and/or arguments. Command Window Anatomy Command output Place for command response, which may be many lines long. Command Window Anatomy Input cursor Typed text will appear at the cursor location. Command Window Anatomy Scroll Bar Will appear as needed when there are more lines than fit in the window. Command Window Anatomy Resize Handle Use the mouse to change the window size from the default 80x24. Command Structure command [arguments] Commands are made up of the actual command and its arguments. command -options [arguments] The arguments are further broken down into the command options which are single letters prefixed by a “-” and other arguments that identify data for the command.
    [Show full text]
  • Secure Telnet
    The following paper was originally published in the Proceedings of the Fifth USENIX UNIX Security Symposium Salt Lake City, Utah, June 1995. STEL: Secure TELnet David Vincenzetti, Stefano Taino, and Fabio Bolognesi Computer Emergency Resource Team Italy Department of Computer Science University of Milan, Italy For more information about USENIX Association contact: 1. Phone: 510 528-8649 2. FAX: 510 548-5738 3. Email: [email protected] 4. WWW URL: http://www.usenix.org STEL Secure TELnet David Vincenzetti Stefano Taino Fabio Bolognesi fvince k taino k b ologdsiunimiit CERTIT Computer Emergency Response Team ITaly Department of Computer Science University of Milan ITALY June Abstract Eavesdropping is b ecoming rampant on the Internet We as CERTIT have recorded a great numb er of sning attacks in the Italian community In fact sning is the most p opular hackers attack technique all over the Internet This pap er presents a secure telnet implementation whichhas b een designed by the Italian CERT to makeeavesdropping ineective to remote terminal sessions It is not to b e considered as a denitive solution but rather as a bandaid solution to deal with one of the most serious security threats of the moment Intro duction STEL stands for Secure TELnet We started developing STEL at the University of Milan when we realized that eavesdropping was a very serious problem and we did not like the freeware solutions that were available at that time It was ab out three years ago Still as far as we know e tapping problem and there are no really satisfying
    [Show full text]
  • System Log Commands
    System Log Commands • system set-log , on page 2 • show system logging-level, on page 3 • show log, on page 4 System Log Commands 1 System Log Commands system set-log system set-log To set the log level and log type of messages, use the system set-log command in privileged EXEC mode. system set-log level {debug | info | warning | error | critical} logtype {configuration | operational | all} Syntax Description level Specifies the log level. debug Logs all messages. info Logs all messages that have info and higher severity level. warning Logs all messages that have warning and higher severity level. error Logs all messages that have error and higher severity level. critical Logs all messages that have critical severity level. logtype Specifies the log type. configuration Configuration log messages are recorded. operational Operational log messages are recorded. all All types of log messages are recorded. Command Default For the configuration log, info is the default level. For the operational log, warning is the default level. Command Modes Privileged EXEC (#) Command History Release Modification 3.5.1 This command was introduced. Usage Guidelines After a system reboot, the modified logging configuration is reset to the default level, that is, info for the configuration log and warning for the operational log. Example The following example shows how to configure a log level: nfvis# system set-log level error logtype all System Log Commands 2 System Log Commands show system logging-level show system logging-level To view the log level and log type settings, use the show system logging-level command in privileged EXEC mode.
    [Show full text]
  • Dell EMC Powerstore CLI Guide
    Dell EMC PowerStore CLI Guide May 2020 Rev. A01 Notes, cautions, and warnings NOTE: A NOTE indicates important information that helps you make better use of your product. CAUTION: A CAUTION indicates either potential damage to hardware or loss of data and tells you how to avoid the problem. WARNING: A WARNING indicates a potential for property damage, personal injury, or death. © 2020 Dell Inc. or its subsidiaries. All rights reserved. Dell, EMC, and other trademarks are trademarks of Dell Inc. or its subsidiaries. Other trademarks may be trademarks of their respective owners. Contents Additional Resources.......................................................................................................................4 Chapter 1: Introduction................................................................................................................... 5 Overview.................................................................................................................................................................................5 Use PowerStore CLI in scripts.......................................................................................................................................5 Set up the PowerStore CLI client........................................................................................................................................5 Install the PowerStore CLI client..................................................................................................................................
    [Show full text]
  • Unix Security
    Unix Security Vulnerability Assessment Course All materials are licensed under a Creative Commons “Share Alike” license. ■ http://creativecommons.org/licenses/by-sa/3.0/ 2 Agenda ■ Why assess ■ Where are we in the process ■ What’s needed ■ Defining vulnerabilities ■ NIST 800-53A controls ■ Assessment Exercise ■ Security Exercise ■ Conclusion 3 Vulnerability Assessment ■ Provides the opportunity to address weaknesses before an enemy can exploit them ■ Implementation: Scanning tools that identify vulnerabilities in computer hardware, software, networks and operating systems ■ Common techniques – Multiple tools – one tool may not identify all vulnerabilities – Ability to identify backdoors security perimeter, e.g. modems, VPNs, etc. – all potential vulnerabilities need to be assessed – Correction verification mechanism – ability to check if vulnerability has been eliminated ■ Compliance with OMB, DOD, DHS policy – Utilize NIST 800-53 and 800-53A – DOD 8500 series 4 What’s Needed ■ Unix experience – Hands on experience: configuration, managing, building various Unix systems – Working knowledge of best practices ■ Security Experience – Intimate knowledge of how to secure a system – Prior experience with CIS Benchmark, DISA STIG/SRR ■ Data Collection – Network scans from NMAP and Nessus – Host output from any data collection tools ■ Other Skills – Need to work with administrators – Put vulnerability in their language – Be tedious while looking for vulnerabilities – Work well in a team 5 Defining Unix Vulnerability Assessment ■ Defining Unix Vulnerability Assessment – Unix Vulnerability Assessment – Unix Security Issues – Security Paradigm – System Hardening: The CIS Philosophy – Network Based Vulnerability Scanning – Host (Local) Vulnerability Scanning – Remote vs. Local Vulnerability Scanning – Common Problems and Issues – Mitigation 6 Unix Vulnerability Assessment ■ Definition – Examining the operating characteristics of a Unix environment remotely and locally in order to accurately assess its security posture (or profile).
    [Show full text]
  • Computer Network Security Protocols: a Review
    International Journal of Enhanced Research in Management & Computer Applications ISSN: 2319-7471, Vol. 5 Issue 1, January-2016 Computer Network Security Protocols: A Review Anil Kumar Programmer-Cum-Networking Engineer, Haryana Roadways, Transport Department, Govt of Haryana, India. ABSTRACT Network security is a complicated subject, historically only tackled by well-trained and experienced experts. However, as more and more people become ``wired'', an increasing number of people need to understand the basics of security in a networked world. This document was written with the basic computer user and information systems manager in mind, explaining the concepts needed to read through the hype in the marketplace and understand risks and how to deal with them. Keywords: Protocol, Security, Secure Socket Layer (SSL) and Transport Layer Security (TLS) Protocols; secure IP (IPSec); Secure HTTP (S-HTTP), secure E-mail (PGP and S/MIME), DNDSEC, SSH. 1. INTRODUCTION The rapid growth of the Internet as bothan individual and business communication channel has created a growing demand forsecurity and privacy in this electronic communication channel. Security and privacy are essential if individual communication is to continue ande-commerce is to thrivein cyberspace. The call for and desire for security and privacy has led to several security protocols and standards. Among these are: Secure Socket Layer (SSL) and Transport Layer Security (TLS) Protocols; secure IP (IPSec); Secure HTTP (S-HTTP), secure E-mail ( PGP and S/MIME), DNDSEC, SSH, and others. In this paper I discuss these protocols and standards within the framework of the network protocol stack as follow: Application Layer Transport Layer Network Layer Data Link Layer: PGP, SSL IPSec PPP S/MIME TLS VPN RADIUS S-HTTP TACACS+ HTTPS SET KERBEROS 2.
    [Show full text]
  • Epmp Command Line Interface User Guide
    USER GUIDE ePMP Command Line Interface ePMP Command Line Interface User Manual Table of Contents 1 Introduction ...................................................................................................................................... 3 1.1 Purpose ................................................................................................................................ 3 1.2 Command Line Access ........................................................................................................ 3 1.3 Command usage syntax ...................................................................................................... 3 1.4 Basic information ................................................................................................................. 3 1.4.1 Context sensitive help .......................................................................................................... 3 1.4.2 Auto-completion ................................................................................................................... 3 1.4.3 Movement keys .................................................................................................................... 3 1.4.4 Deletion keys ....................................................................................................................... 4 1.4.5 Escape sequences .............................................................................................................. 4 2 Command Line Interface Overview ..............................................................................................
    [Show full text]
  • Filesystem Hierarchy Standard
    Filesystem Hierarchy Standard LSB Workgroup, The Linux Foundation Filesystem Hierarchy Standard LSB Workgroup, The Linux Foundation Version 3.0 Publication date March 19, 2015 Copyright © 2015 The Linux Foundation Copyright © 1994-2004 Daniel Quinlan Copyright © 2001-2004 Paul 'Rusty' Russell Copyright © 2003-2004 Christopher Yeoh Abstract This standard consists of a set of requirements and guidelines for file and directory placement under UNIX-like operating systems. The guidelines are intended to support interoperability of applications, system administration tools, development tools, and scripts as well as greater uniformity of documentation for these systems. All trademarks and copyrights are owned by their owners, unless specifically noted otherwise. Use of a term in this document should not be regarded as affecting the validity of any trademark or service mark. Permission is granted to make and distribute verbatim copies of this standard provided the copyright and this permission notice are preserved on all copies. Permission is granted to copy and distribute modified versions of this standard under the conditions for verbatim copying, provided also that the title page is labeled as modified including a reference to the original standard, provided that information on retrieving the original standard is included, and provided that the entire resulting derived work is distributed under the terms of a permission notice identical to this one. Permission is granted to copy and distribute translations of this standard into another language, under the above conditions for modified versions, except that this permission notice may be stated in a translation approved by the copyright holder. Dedication This release is dedicated to the memory of Christopher Yeoh, a long-time friend and colleague, and one of the original editors of the FHS.
    [Show full text]
  • Powerview Command Reference
    PowerView Command Reference TRACE32 Online Help TRACE32 Directory TRACE32 Index TRACE32 Documents ...................................................................................................................... PowerView User Interface ............................................................................................................ PowerView Command Reference .............................................................................................1 History ...................................................................................................................................... 12 ABORT ...................................................................................................................................... 13 ABORT Abort driver program 13 AREA ........................................................................................................................................ 14 AREA Message windows 14 AREA.CLEAR Clear area 15 AREA.CLOSE Close output file 15 AREA.Create Create or modify message area 16 AREA.Delete Delete message area 17 AREA.List Display a detailed list off all message areas 18 AREA.OPEN Open output file 20 AREA.PIPE Redirect area to stdout 21 AREA.RESet Reset areas 21 AREA.SAVE Save AREA window contents to file 21 AREA.Select Select area 22 AREA.STDERR Redirect area to stderr 23 AREA.STDOUT Redirect area to stdout 23 AREA.view Display message area in AREA window 24 AutoSTOre ..............................................................................................................................
    [Show full text]
  • Unix Security Overview: 1
    CIS/CSE 643: Computer Security (Syracuse University) Unix Security Overview: 1 Unix Security Overview 1 User and Group • Users – root: super user (uid = 0) – daemon: handle networks. – nobody: owns no files, used as a default user for unprivileged operations. ∗ Web browser can run with this mode. – User needs to log in with a password. The encrypted password is stored in /etc/shadow. – User information is stored in /etc/passwd, the place that was used to store passwords (not anymore). The following is an example of an entry in this file. john:x:30000:40000:John Doe:/home/john:/usr/local/bin/tcsh • Groups – Sometimes, it is more convenient if we can assign permissions to a group of users, i.e. we would like to assign permission based on groups. – A user has a primary group (listed in /etc/passwd), and this is the one associated to the files the user created. – Any user can be a member of multiple groups. – Group member information is stored in /etc/group % groups uid (display the groups that uid belongs to) – For systems that use NIS (Network Information Service), originally called Yellow Page (YP), we can get the group information using the command ypcat. % ypcat group (can display all the groups and their members) 2 File Permissions • File Permissions – The meaning of the permission bits in Unix. ∗ Owner (u), Group (g), and Others (o). ∗ Readable (r), Writable (w), and Executable (x). ∗ Example: -rwxrwxrwx (777) • Permissions on Directories: – r: the directory can be listed. – w: can create/delete a file or a directory within the directory.
    [Show full text]