LPI Linux Certification in a Nutshell Part 39

dig dig is the most complete and powerful DNS utility and is available in most Unix/Linux systems. The tool will use the default nameservers defined in the is the most complete and powerful DNS utility and is available in most Unix/Linux systems. The tool will use the default nameservers defined in the resolv.conf resolv.conf file: file: #digwww.oreilly.com

;<>>DiG9.4.3-P1<>>www.oreilly.com ;;globaloptions:printcmd ;;Gotanswer: ;;->>HEADER<-opcode:query,status:noerror,id:17863 ;;flags:qrrdra;query:1,answer:3,authority:0,additional:0="">

;;QUESTIONSECTION: ;www.oreilly.com.INA

;;ANSWERSECTION: www.oreilly.com.161INCNAMEoreilly.com.

oreilly.com.448INA100.201.239.100 oreilly.com.448INA100.201.239.101

;;Querytime:4msec ;;SERVER:100.100.0.43#53(100.100.0.43) ;;WHEN:MonDec1414:48:552009 ;;MSGSIZErcvd:79 Sometimes it's also useful to query nameservers other than the default. This can be done without changing the default address in resolv.conf resolv.conf, by using @ @ plus the nameserver's IP address: plus the nameserver's IP address: [email protected]

;<>>DiG9.4.3-P1<>>www.oreilly.com ;;globaloptions:printcmd ;;Gotanswer: ;;->>HEADER<-opcode:query,status:noerror,id:17863 ;;flags:qrrdra;query:1,answer:3,authority:0,additional:0="">

;;QUESTIONSECTION: ;www.oreilly.com.INA

;;ANSWERSECTION: www.oreilly.com.161INCNAMEoreilly.com.

oreilly.com.448INA100.201.239.100 oreilly.com.448INA100.201.239.101

;;Querytime:4msec ;;SERVER:10.20.10.10#53(10.20.10.10) ;;WHEN:MonDec1414:48:552009 ;;MSGSIZErcvd:79 If PTR (reverse) records are missing, this can affect many network services that rely on these records, such as SSH. PTR records provide a way to map an IP address back to a fully qualified domain name. All reverse lookups should be configured when adding new addresses or changing addresses on the server. dig dig can be used to validate the presence of the PTR records: can be used to validate the presence of the PTR records: #digx208.201.239.100

;<>>DiG9.4.3-P1<>>-x208.201.239.100 ;;globaloptions:printcmd ;;Gotanswer: ;;->>HEADER<-opcode:query,status:noerror,id:28685 ;;flags:qrrdra;query:1,answer:1,authority:0,additional:0="">

;;QUESTIONSECTION: ;100.239.201.208.in-addr.arpa.INPTR

;;ANSWERSECTION: 100.239.201.208.in-addr.arpa.3600INPTRoreilly.com.

;;Querytime:298msec ;;SERVER:10.20.10.10#53(10.20.10.10) ;;WHEN:MonDec1415:01:012009 ;;MSGSIZErcvd:71 The mail exchange (MX) record for a domain defines the server that accepts SMTP email for that domain. To search for the MX records for a specific domain, use: #digmxwww.oreilly.com

;<>>DiG9.4.3-P1<>>mxoreilly.com ;;globaloptions:printcmd ;;Gotanswer: ;;->>HEADER<-opcode:query,status:noerror,id:31415 ;;flags:qrrdra;query:1,answer:2,authority:0,additional:0="">

;;QUESTIONSECTION: ;oreilly.com.INMX

;;ANSWERSECTION: oreilly.com.3600INMX20smtp10.oreilly.com.

oreilly.com.3600INMX20smtp20.oreilly.com.

;;Querytime:153msec ;;SERVER:10.20.10.10#53(10.20.10.10) ;;WHEN:MonDec1415:08:192009 ;;MSGSIZErcvd:73On the ExamBe familiar with the basics of the dig dig syntax and how it's used to query DNS information. syntax and how it's used to query DNS information.

Chapter22.Security (Topic 110.1)

A system is only as secure as the administrator. Although some operating systems may claim better security than others, this is always the "out-of-the-box" type of security. Any system, no matter how secure initially, can become insecure if poorly maintained. It is the responsibility of the system administrator to take an active hand in security, and address both active and pa.s.sive threats. As with most things, the first step is knowledge. Understanding how your system works and what tools are available is fundamental to securing your system. This chapter covers the first Objective of Topic 110: Objective 1: Perform Security Administration Tasks Candidates should know how to review system configuration to ensure host security in accordance with local security policies. This includes topics such as SUID/SGID bits, pa.s.sword aging and good pa.s.sword policy, discovery tools such as nmap nmap, netstat netstat, and lsof lsof, limiting user actions, and giving select users elevated privileges. Weight: 3.

Objective 1: Perform Security Administration Tasks Since everything in Linux is a file, filesystem level security is a core concept that must be understood and implemented properly. The standard Unix security model (which most Linux file systems adopt) is a relatively simple permissions-based model, but it is sufficient for most permissions needs. For more information on the details of the Unix permissions-based security model, refer to the section Changing access modes Changing access modes.

When a user executes a program in Linux, that program is sp.a.w.ned as a subprocess (or subsh.e.l.l) of the user's current sh.e.l.l. This subprocess is known as a child process child process, and is defined in depth in the section Objective 5: Create, Monitor, and Kill Processes Objective 5: Create, Monitor, and Kill Processes. From a security standpoint, the important thing to remember about child processes is that they inherit the security context of the parent process. So if the user adam adam executes a program, that program will have access to the same files and directories that the user executes a program, that program will have access to the same files and directories that the user adam adam normally has (no more, and no less). normally has (no more, and no less).

However, this is not always a desirable situation. One of the criticisms of the standard Linux security model is that it is not fine-grained enough, i.e., you're either a regular user with little or no privileges, or you are the superuser (root) with all privileges. Often, we want the ability to elevate certain users to superuser status for short periods of time, or to execute certain commands, or we want certain commands themselves to execute with elevated privileges, regardless of who executes them. There are ways to handle all of these situations in Linux: SUID and SGID bits, and the commands sudo sudo and and su su.

Changing access modes describes the different security modes that are available to files in Linux. These are normally read, write, or execute. One of the "special" modes available is describes the different security modes that are available to files in Linux. These are normally read, write, or execute. One of the "special" modes available is s s. When the mode s s is a.s.signed to owner permissions on an executable file, we say that file has the SUID (or SetUID) bit set. When the mode is a.s.signed to owner permissions on an executable file, we say that file has the SUID (or SetUID) bit set. When the mode s s is a.s.signed to group permissions on an executable file, we say that file has the SGID (or SetGID) bit set. is a.s.signed to group permissions on an executable file, we say that file has the SGID (or SetGID) bit set.

SUID means that no matter the security context of the parent process running the executable, the executable will run with the security context of the owner of the executable file. This is most commonly used to give regular users the ability to run programs that require root access without actually giving them access to the root account. So if an executable file has the SUID bit set and the file is owned by root, then no matter who executes that file, the resulting process will have root-level permissions.

An example of this is the ping ping command. command. ping ping is used to send ICMP packets to hosts on a network and report back on replies. It is primarily a network testing tool, and is a standard part of every operating system that supports TCP/IP. is used to send ICMP packets to hosts on a network and report back on replies. It is primarily a network testing tool, and is a standard part of every operating system that supports TCP/IP. Ping Ping needs the ability to open a raw network socket in order to do its job, and that kind of low-level access is reserved for the root user. However, it's such a useful and ubiquitous tool, it's common to want to make it available to all users on a system. So in many Linux distributions, needs the ability to open a raw network socket in order to do its job, and that kind of low-level access is reserved for the root user. However, it's such a useful and ubiquitous tool, it's common to want to make it available to all users on a system. So in many Linux distributions, ping ping has the SUID bit set by default. Any user that runs the has the SUID bit set by default. Any user that runs the ping ping command will run it in the security context of the root user. command will run it in the security context of the root user.

Here is what a directory entry for ping ping looks like: looks like: $ls-l/bin/ping -rwsr-xr-x1rootroot423602008-09-2601:02/bin/ping The s s in the user section of the file security setting means that the SUID bit is set. in the user section of the file security setting means that the SUID bit is set.

SGID works in the same way, but for group owners.h.i.+p instead of user owners.h.i.+p.

The (In)Security of SUID Although SUID is a useful option when it comes to delegating roles to nonroot users, its potential security vulnerabilities should not be overlooked. A program marked with the SUID bit and owned by root will run as root. Everything that that program is able to do will be done as the root user. This has large implications for the overall security of a system. Think of this example: vi vi is a common editor that is found on most Linux systems. If is a common editor that is found on most Linux systems. If /bin/vi /bin/vi is SUID, every user who edits any file with is SUID, every user who edits any file with vi vi will have the privileges of the root user, meaning that any user could edit will have the privileges of the root user, meaning that any user could edit any any file on the system. This is the kind of thing that makes SUID so potentially dangerous. There is a situation worse than being able to edit any file as root: sp.a.w.ning a subsh.e.l.l from an SUID program. We can use file on the system. This is the kind of thing that makes SUID so potentially dangerous. There is a situation worse than being able to edit any file as root: sp.a.w.ning a subsh.e.l.l from an SUID program. We can use vi vi as our example here again. The editor as our example here again. The editor vi vi allows you to issue a command to sp.a.w.n a subsh.e.l.l while you are in the editor. We know that a child process inherits the security context of the parent process. So if allows you to issue a command to sp.a.w.n a subsh.e.l.l while you are in the editor. We know that a child process inherits the security context of the parent process. So if vi vi is SUID and it sp.a.w.ns an interactive sh.e.l.l child process, that interactive sh.e.l.l has a security context of is SUID and it sp.a.w.ns an interactive sh.e.l.l child process, that interactive sh.e.l.l has a security context of root root. So the simple act of making /bin/vi /bin/vi SUID has given all users on the system an easy way to access an interactive sh.e.l.l prompt as the root user, completely undermining all other security protocols that might be in place. SUID has given all users on the system an easy way to access an interactive sh.e.l.l prompt as the root user, completely undermining all other security protocols that might be in place.

Because of this potentially dangerous situation, a good system administrator must be aware of what programs on his system have the SUID and/or SGID bit set. The find find command (described in depth in command (described in depth in Chapter6 Chapter6) has an option to search for files based on their permissions. Here is an example: #find/bin-perm-4000-typef /bin/mount /bin/su /bin/ping /bin/ping6 /bin/umount /bin/fusermount The -perm -4000 -perm -4000 option to option to find find says, "Only display files that have the SUID bit set." The number 4000 is the octal representation of the security mode for a file. Reading from right to left, the first 0 is for "other" permissions, the next 0 is for "group" the third 0 is for "owner," and the 4 represents SUID. An equivalent way to write this using symbolic modes instead of the octal representation is says, "Only display files that have the SUID bit set." The number 4000 is the octal representation of the security mode for a file. Reading from right to left, the first 0 is for "other" permissions, the next 0 is for "group" the third 0 is for "owner," and the 4 represents SUID. An equivalent way to write this using symbolic modes instead of the octal representation is -perm u=s -perm u=s, as in "find all files that have the 's' bit set in the user mode section."

It is important to understand why some programs have the SUID bit set. Some programs (such as ping ping) are not required by the operating system, and it is therefore safe to remove the SUID bit from them. Some programs (such as pa.s.swd pa.s.swd) need to be SUID to ensure they function correctly on the operating system (if you remove the SUID bit from the pa.s.swd pa.s.swd command, then users cannot change their own pa.s.swords). If the SUID bit is not required in your situation, remove it: command, then users cannot change their own pa.s.swords). If the SUID bit is not required in your situation, remove it: #ls-l/bin/ping -rwsr-xr-x1rootroot423602008-09-2601:02/bin/ping #chmod-s/bin/ping #ls-l/bin/ping -rwxr-xr-x1rootroot423602008-09-2601:02/bin/ping # Now only the superuser will be able to use the ping ping command. command.

In addition to the SUID and SGID bit, the commands su su and and sudo sudo can be used to elevate the privileges of a regular user. can be used to elevate the privileges of a regular user.

User IDs and Pa.s.swords Users in the Unix world are most commonly referred to by their usernames, but that is not how the underlying operating system sees them. Every user on a system is a.s.signed a user ID (UID) that uniquely identifies that user. UIDs are integers ranging from 0 to 65535. UID 0 is reserved for the superuser (commonly named root root, but the name can in fact be anything, as long as the UID is 0). Convention dictates that "system" users (user accounts that represent system processes, not actual human beings) have UIDs below 100.

Because everything in Unix is a file, the file security permissions are of utmost importance. The owner and group owner of a file is stored in the inode (index node) at the filesystem level. This is stored as the UID integer, not as the username. To see an example of this, do a long directory listing on a directory where some files are owned by users that no longer exist on the system: #cd/var/spool/mail/ #ls-l total1295140 -rw-rw----1adamhmail0Jan611:04adamh -rw-rw----1alexmail86311334Jan806:27alex -rw-rw----12047mail0Dec22006alice -rw-rw----12003mail1600945Jan72009bob -rw-rw----12080mail95086Sep92008carol In this example, we are looking in the directory /var/spool/mail /var/spool/mail, where the mail spool files for each user are stored, with filenames corresponding to user account names. The files adamh adamh and and alex alex are owned by users are owned by users adamh adamh and and alex alex, respectively, whereas the file alice alice is owned by UID 2047, is owned by UID 2047, bob bob is owned by 2003, and is owned by 2003, and carol carol is owned by 2080. This reflects the fact that owners.h.i.+p is stored in the inode by integer (the UID). In this case, the users is owned by 2080. This reflects the fact that owners.h.i.+p is stored in the inode by integer (the UID). In this case, the users alice alice, bob bob, and carol carol no longer have accounts on the system, but these files still reflect that they are owned by these (now una.s.signed) UIDs. The no longer have accounts on the system, but these files still reflect that they are owned by these (now una.s.signed) UIDs. The ls ls command will display the username instead of the UID by default in a long directory listing (unless the command will display the username instead of the UID by default in a long directory listing (unless the -n -n option is pa.s.sed to option is pa.s.sed to ls ls) because we human beings are better at remembering names than numbers. If ls ls is able to resolve a UID to a username, it will display the username; if not, it displays the UID. is able to resolve a UID to a username, it will display the username; if not, it displays the UID.

The file /etc/pa.s.swd /etc/pa.s.swd acts as the source for username-to-UID mapping (unless a system such as NIS is in use, which is not covered on LPI 102). This file is the source for all user accounts on the system, and contains not only username information, but also other information about the user account, such as that user's home directory and default sh.e.l.l. The following is an example section from acts as the source for username-to-UID mapping (unless a system such as NIS is in use, which is not covered on LPI 102). This file is the source for all user accounts on the system, and contains not only username information, but also other information about the user account, such as that user's home directory and default sh.e.l.l. The following is an example section from /etc/pa.s.swd /etc/pa.s.swd: #more/etc/pa.s.swd root:x:0:0:root:/root:/bin/bash bin:x:1:1:bin:/bin:/sbin/nologin daemon:x:2:2:daemon:/sbin:/sbin/nologin adm:x:3:4:adm:/var/adm:/sbin/nologin lp:x:4:7:lp:/var/spool/lpd:/sbin/nologin adamh:x:500:504:AdamHaeder:/home/adamh:/bin/bash Each colon-delimited line represents one user account. Table22-1 Table22-1 defines these fields. defines these fields.

Table22-1.Fields in /etc/pa.s.swd

Field position Name Description 1 Username A human-readable name, 132 characters in length. Only letters, numbers, underscores, and dashes are allowed.

2 Pa.s.sword Formerly stored a user's encrypted pa.s.sword string. If shadow pa.s.swords are in use, this field always contains the placeholder x. (Shadow pa.s.swords are covered in more depth later in this chapter.) 3 User ID (UID) The integer from 065535 that identifies a user.

4 Group ID (GID) The integer from 065535 that identifies the user's primary group members.h.i.+p.

5 Comments Textual information about a user. This field usually contains a user's full name or possibly his phone number. Referred to as the GECOS field for historical reasons (early Unix machines used a General Electric Comprehensive Operating Supervisor machine for printing, so this field was created to store a Unix user's GECOS ident.i.ty).

6 Home directory The absolute path to the directory the user will be in upon successful login. This directory commonly is owned by that user.

7 Default sh.e.l.l The program that runs when the user logs in. When this program is exited, the user is logged out of the system. This is usually an interactive sh.e.l.l program (such as /bin/bash) but it can be another executable program as well.

Let's take a look at the user adamh adamh from our previous example: from our previous example: adamh:x:500:504:AdamHaeder:/home/adamh:/bin/bash Field 3 tells us that the UID for adamh adamh is 500, and field 4 tells us that the GID for is 500, and field 4 tells us that the GID for adamh adamh is 504. Many Linux distributions will start "normal" user UIDs at 500, reserving UIDs from 1499 for system accounts. Field 5 tells us that his full name is Adam Haeder, field 6 says his home directory is is 504. Many Linux distributions will start "normal" user UIDs at 500, reserving UIDs from 1499 for system accounts. Field 5 tells us that his full name is Adam Haeder, field 6 says his home directory is /home/adamh, /home/adamh, and finally, field 7 says that when he successfully logs in, the program and finally, field 7 says that when he successfully logs in, the program /bin/bash /bin/bash will be executed. will be executed.

/etc/pa.s.swd is a text file, and therefore it can be edited like any other text file. However, that is a bad practice to get into because a syntax error in this file can prevent users (even is a text file, and therefore it can be edited like any other text file. However, that is a bad practice to get into because a syntax error in this file can prevent users (even root root) from logging into the system. A much better way to maintain the /etc/pa.s.swd /etc/pa.s.swd file is with the command file is with the command /usr/sbin/usermod /usr/sbin/usermod.

Shadow Pa.s.swords Why is there an x x in the pa.s.sword field (field 2) of the previous example? When Unix was originally designed, the in the pa.s.sword field (field 2) of the previous example? When Unix was originally designed, the /etc/pa.s.swd /etc/pa.s.swd file stored a user's encrypted pa.s.sword string in field 2 of file stored a user's encrypted pa.s.sword string in field 2 of /etc/pa.s.swd /etc/pa.s.swd. The pa.s.sword was encrypted using an algorithm known as a one-way hash (the crypt crypt algorithm), meaning that while it was trivial to convert a string to a hashed value, it was mathematically difficult (i.e., it would take an extremely long time) to convert the hashed value back to the original string. This is a common function of algorithms used in the security world, especially for things such as pa.s.swords. If you can't determine the original pa.s.sword when you only know the hashed value, then we don't have to worry about the security around the hashed value itself, because it is too difficult mathematically to derive the pa.s.sword from the hashed value. So this hashed value can be stored in a world-readable file such as algorithm), meaning that while it was trivial to convert a string to a hashed value, it was mathematically difficult (i.e., it would take an extremely long time) to convert the hashed value back to the original string. This is a common function of algorithms used in the security world, especially for things such as pa.s.swords. If you can't determine the original pa.s.sword when you only know the hashed value, then we don't have to worry about the security around the hashed value itself, because it is too difficult mathematically to derive the pa.s.sword from the hashed value. So this hashed value can be stored in a world-readable file such as /etc/pa.s.swd /etc/pa.s.swd without compromising the security of the system. without compromising the security of the system.

If it's very difficult to derive a pa.s.sword from its hashed value, how does the system know I'm typing in the right pa.s.sword when I log in? The login process on a Linux system follows these steps: 1. Prompt user for a username and pa.s.sword.

2. Look in /etc/pa.s.swd /etc/pa.s.swd to see whether the user account exists. to see whether the user account exists.

3. If it does, encrypt the string given as the pa.s.sword using the crypt crypt algorithm. algorithm.

4. Compare the encrypted string given by the user with the encrypted string stored in field 2 of the /etc/pa.s.swd /etc/pa.s.swd entry for that username. If they match, then the user gave the correct pa.s.sword, and she is allowed to log in. If they did not match, present an error and ask the user for the pa.s.sword again. entry for that username. If they match, then the user gave the correct pa.s.sword, and she is allowed to log in. If they did not match, present an error and ask the user for the pa.s.sword again.

In this way, a Linux system is able to determine whether a user provided the correct pa.s.sword without having to "recover" the original pa.s.sword from the encrypted string.

Although this solution is effective, it does pose security risks. By storing the encrypted string in the world-readable /etc/pa.s.swd /etc/pa.s.swd file, any user on the system has access to every other user's encrypted pa.s.sword. It may be extremely difficult for a user to mathematically derive the original pa.s.sword from the encrypted string, but she can use the same file, any user on the system has access to every other user's encrypted pa.s.sword. It may be extremely difficult for a user to mathematically derive the original pa.s.sword from the encrypted string, but she can use the same crypt crypt algorithm to encrypt random strings and compare the resultant encrypted string with the encrypted strings for other users (following the same process that the login program uses). If the user is patient enough and tries enough combinations of letters and numbers, she could eventually find a string that, after encryption, exactly matches the encrypted string for a user account. This is called a algorithm to encrypt random strings and compare the resultant encrypted string with the encrypted strings for other users (following the same process that the login program uses). If the user is patient enough and tries enough combinations of letters and numbers, she could eventually find a string that, after encryption, exactly matches the encrypted string for a user account. This is called a brute force attack brute force attack, because the user is forced to try every possible combination of potential pa.s.swords to determine which one is correct.

If this seems like a daunting and time-consuming task, that's because it is. Or at least it was, if we're talking about the computing power that was available to the average user in the 1960s through the 1980s. However, as the 1980s turned into the 1990s, and computers not only got much faster but also much cheaper, the average user had access to relatively powerful computational machines that could encrypt strings and compare them against other encrypted strings at the rate of thousands (or hundreds of thousands) per second. This posed a problem for the system administrators of the day; the encrypted hash was stored in a world-readable file (/etc/pa.s.swd), and every user could now copy this file, take it back to their personal computers, and run brute force attacks against it.

The solution to this was to move the encrypted pa.s.sword string to a file that is not world-readable. Thus the concept of shadow pa.s.swords shadow pa.s.swords was born, and the file was born, and the file /etc/shadow /etc/shadow was created. This file contains not only the encrypted pa.s.sword but also other user account fields that are important (such as pa.s.sword age and account expiration dates), without requiring a modification to the format of was created. This file contains not only the encrypted pa.s.sword but also other user account fields that are important (such as pa.s.sword age and account expiration dates), without requiring a modification to the format of /etc/pa.s.sword /etc/pa.s.sword. Plus, only the root user can read /etc/shadow /etc/shadow, preventing brute force attacks by normal users.

The /etc/shadow /etc/shadow file is colon-delimited, like file is colon-delimited, like /etc/pa.s.swd /etc/pa.s.swd, and contains the fields described in Table22-2 Table22-2.

Table22-2.Fields in /etc/shadow

Field position Name Description 1 Username Must match a username in /etc/pa.s.swd.

2 Pa.s.sword Encrypted pa.s.sword string. Other special options here are: ! or or null null: This account has no pa.s.sword.

*: Account is disabled.

!: Account is locked.

!!: Pa.s.sword has never been set.

3 Last Changed The number of days (since January 1, 1970) since the pa.s.sword was last changed.

4 Minimum The number of days before a user may change his pa.s.sword. A value of 0 means the user may change his pa.s.sword at any time.

5 Maximum The number of days a user can keep the same pa.s.sword. After this limit is reached, the user must change his pa.s.sword. Usually set to 99999 if pa.s.sword changes are not required.

6 Warn The number of days before pa.s.sword expiration that a user starts to receive warnings.

7 Inactive The number of days after pa.s.sword expiration that an account is automatically disabled.

8 Expire A number indicating when the account will be disabled. This is represented as the number of days since January 1, 1970.

9 Reserved Reserved for possible future use.

Here is the section of /etc/shadow /etc/shadow that corresponds to the section of that corresponds to the section of /etc/pa.s.swd /etc/pa.s.swd listed previously: listed previously: root:$1$8jp/RdHb$D1x/6Xr2.puE0NX3nIgdX/:14617:0:99999:7::: bin:*:13993:0:99999:7::: daemon:*:13993:0:99999:7::: adm:*:13993:0:99999:7::: lp:*:13993:0:99999:7::: adamh:$1$IqH21LHP$BJPha9o6/XoOsSoJfWLfZ0:14617:0:99999:7:::NoteThese are actual encrypted pa.s.sword strings. Break out your favorite brute-force pa.s.sword-cracking program and see if you can figure out the pa.s.swords.

We can see from this file that the root account has a pa.s.sword, the pa.s.sword was last changed 14,617 days after January 1, 1970, this user can change her pa.s.sword at any time, she does not have to change her pa.s.sword until 99,999 days after January 1, 1970, and if her pa.s.sword is ever set to expire, she will start getting notices 7 days before the actual expiration.

You can use the date date command to determine the actual dates those integer values represent: command to determine the actual dates those integer values represent: #echo"Thepa.s.swordfortherootaccountwaslastchanged on'date-d"1970/01/01+14617days"'"

Thepa.s.swordfortherootaccountwaslastchanged onFriJan800:00:00CST2010 #echo"Thepa.s.swordforthebinaccountwaslastchanged on'date-d"1970/01/01+13993days"'"