Showing posts with label gid. Show all posts
Showing posts with label gid. Show all posts

Friday, November 21, 2008

Another Simple Scriptlet To Make The Unix And Linux CLI More User Friendly

Hey there,

Today we're going to shoot out another quick scriptlet that might be useful (or distracting ;) from time to time. It’s a bit of a follow up on our post from earlier this week on using bash to produce fancy user names for folks logged into your machine, although it’s a little bit longer. Once again, if you go by the 65 character rule, this isn’t a one liner, even though it’s all going on one line ;)

Our little foray into variable interpolation today has to do with making /etc/passwd just a bit more accessible. Most folks are familiar with the 7 colon-separated fields of this file (if not, they’re: The user’s Username, an encrypted password (or usually an “x” if you’re using a shadow password system), the user’s UID, the user’s GID, the user’s gecos information (Also referred to as the “comment field,” usually either empty or populated with a short description to make the account more easily recognizable) , the user’s home directory and, finally, the user’s default shell)

Now, say what you will about the structure and setup of the passwd file, but it’s fairly easy to follow. Almost everything in it is the opposite of cryptic. The password field (field number 2) is, of course, not going to be tailored for your ease of understanding ;) If you get really lucky and you hop on a machine that actually lists the encrypted password in field two of /etc/passwd, you can copy the file to any remote machine and go to work on it. We've posted quite a few scripts to do automated password cracking. You should just see an "x" for a standard user account. If you don’t, have a talk with your SysAdmin or, if you’re him, please move on to a shadowed password system. Too much information exists in the public domain to make the old-style setup anything more than a trifling hassle to someone who wants to exploit your system. Especially a disgruntled employee!

Other than that, the user ID (field number 3) is an easy relation to make, since the username is in the same file (field number 1). The only thing in there that doesn’t practically explain itself is field number 4; the GID (group id) field. It’s not that big of a deal to look a user up in /etc/passwd, glean that group id information and find out what group the user is in by looking at /etc/group. It’s as simple as this:

host # grep user1 /etc/passwd
user1:x:37527:501::/export/home/user1:/bin/bash
host # grep 501 /etc/group
people::501:


and, just like that, we know that the user "user1"'s primary group membership is in the group "people." There are also secondary groups to consider, but finding this out is trivial as well. Just do the following:

host # grep -w user1 /etc/group
guys::600:user1
folks::601:user1


And, yes, I can hear you out there ;) I'm aware of commands like "groups" and "id" ;) They're very good at getting this information, as well (which is why we're going to use "groups" in our one-long-liner. Your output may look slightly different). Note that some versions don't have the -a option for "id" and some have either -g, -G, any combination of the three or all of them - it depends on your distro:

host # groups <-- This is supposed to list groups in order, from left to right, with the leftmost group being the "primary" and every group after that being a "secondary." The ordering of the "secondary" groups in the list is generally "as they appear" in /etc/group. So, since the line with "guys" is on a line closer to the beginning of the /etc/group file than the line with "folks," they're printed in that order. No other relationship exists between them that I'm aware of.
people guys folks
host # id -a
uid=37527(user1) gid=501(people) groups=501(people)
<-- On Solaris; not quite as helpful as "id" on other flavours of Linux or Unix.

Anyway, I think I've met my word-count quota ;) Just kidding. I have no idea how much I've typed. I'm not even sure I want to know...

Here's a nice little command line (and, consequently, the topic of this post ;) to print every user's group(s) in the (modified) output of /etc/passwd. Just type it out, like so:

host # IFSBAK=$IFS;export IFS=":";while read one two three four five;do groupnames=`groups $one|sed 's/ /,/g'`;echo "${one}:${two}:${three}:${groupnames}:${five}";done </etc/passwd;export IFS=$IFSBAK


...lots of output left out for reasons of brevity and security :) ...
noaccess:x:60002:noaccess:No Access User:/
user1:x:37527:people,guys,folks::/export/home/user1:/bin/bash
...


And, there we have it. All nice and tidy :) Here's the same thing in script format (below) to make it a little easier to read. Be sure (now matter how you run it) that you don't clip the beginning and end, as you'll probably want to reset your shell's IFS (field separator) to what it was before we changed it to the colon (:) to make parsing /etc/password possible without using awk or cut, etc... Also, if it's of any interest and you noted that I only counted my variables up to "five" it's because "while read" will swallow up the rest of a line in its last variable. So, instead of reading and writing five, six and seven, I just read five, since that would include from field five all the way to the end of the line (at the end of field 7), and field 4 (the group field) was the last field on every line that we were actually interested in :)

#!/bin/bash

IFSBAK=$IFS
export IFS=":"

while read one two three four five
do
groupnames=`groups $one|sed 's/ /,/g'`
echo "${one}:${two}:${three}:${groupnames}:${five}"
done </etc/passwd

export IFS=$IFSBAK


Have a great weekend!

, Mike




Please note that this blog accepts comments via email only. See our Mission And Policy Statement for further details.

Thursday, July 3, 2008

UnConfusing The Issue Of Disabling Root On Linux or Unix

Hey There,

Loosely following up on a few previous posts regarding securing Linux and Unix and even more fun with Unix and Linux security, today we're going to look at something vaguely security-related, and also vaguely scary ;)

It has to do with the root account (or user id 0) and security hardening. I've got nothing against either, so this won't be an insane diatribe, but (especially, no offense to Ubuntu) with more Linux distro's coming straight out-of-the-box with root disabled, I see the issue of security and the root user get a little confused. A lot ;)

There are a numbers of things at issue here, and they're all loosely tied-together by the common thread of an earnest striving for better total-system security. Today, I'm just feeling like clearing some of them up to the best of my ability, before they make me nuts.

1. Having a disabled root account and removing a root account are two entirely separate things. As I mentioned above, Ubuntu comes with the root account disabled (basically, you can do this on any OS by running "passwd -l root" as the root user, hopefully setting a regular user up with a sudo rule so they can su to root if they need to later, and then exiting out of the root account).

This is perfectly fine. It upsets quite a few people who don't know what to make of it, initially, but it's not a bad idea. The root user's password is locked, so no one can su to it without sudo (or some other privilege-escalation vehicle), but the account still exists and runs as normal.

It goes without saying, at this point in the post, that actually removing root (userdel root will fail - probably too late - but you can accomplish almost the same thing by editing /etc/passwd, /etc/group, /etc/security/*, etc, as root and logging out) is a bad idea. The problem then becomes that, not only can no one su to root, it's actually gone, and everything that used to run as uid 0 will begin to exhibit bizarre behaviour. Without intervention you can expect to lose your system fairly quickly and have the boot process crash on you as soon as it gets to running init, at best. By default, on almost every system I know, init runs as root, spawning "init" (process 1 - the mother of them all). If that can't start, what else can? I've heard tell of systems that will revert to the nobody account to run this, but I've never seen it happen and I can't imagine how it would work...

2. There are ways to run your system without having a root user, but almost all of them are not worth the effort. As a blanket statement, if you replace the root account with another account with uid 0 (Except in such instances as FreeBSD, where they've gone through the trouble of actually coding out a "toor" user as a root variant), you're opening up the door to any number of problems you may have not foreseen. Replacing uid 0 with uid 100034 (pick a number) would be even more probable to cause stress-related fatalities ;) Liken it to the old-style firewall security method of "block what you don't want and let everything else in." That philosophy was eventually replaced by the more sensible "block everything and only let in what you want" method. If you mess with root, or uid 0, you may have a huge list of things you've accounted for, but you're almost guaranteed to stung by something you'd (and anybody else probably would have) forgotten or never even considered.

3. Changing init in Linux using the boot loader (with arguments like init=/bin/bash) doesn't actually address the issue with running init without root, or a user with uid 0. This trick can come in very handy when, for instance, you want to subvert LILO or Grub security and boot into bash. Of course, / will be mounted read-only, but it's only a minor inconvenience to run "mount -o rw,remount" on it to begin editing files you shouldn't be editing. Of course, you'd only end up doing this if you were in it deep and had to manually edit your /etc/shadow file or something, right? Yes. That's the ethical answer :) As far as hardening security goes, I'm not sure how this misconception got started.

4. Having more than one user with uid 0, or more than one group with gid 0, is not only insane, it's lazy-insane ;) Seriously, I've seen this proposed as an alternative to locking root's password and using sudo in order for certain users to access root to make changes as the superuser. There are a few issues with this sort of convenience, none of which are good (except, that 5 or 6 guys on your system have uid 0 and root privilege which is great! ...I mean bad). Aside from the simple "plus 1" factor of risk-of-accidental-keystroke-downing-your-machine incidents per user with said privilege, having multiple users with the same uid and/or gid can cause erratic behaviour with programs that do name-to-uid and/or uid-to-name mapping (like the login command).

All of this comes back to locking up the root user password. This is (assuming you have to pick from that and the 4 options above) the most sane choice. I'm not gonna shine you on about how I've never used root as my main account for years on end and haven't ever accidentally deleted the /dev filesystem (well, at least as much as it would let me before there was no device left to do the deleting ;) I've done lots of crazy and irresponsible things in my career and, according to some folks (like the U.S. military and heavy-hitting banking and/or securities-trading companies) I still do, no matter how good I try to be ;)

But I think, if you must tighten the screws on the root account, then look to Ubuntu's example and have the default setup with a locked root password and a user account that can "sudo su" to it. There's no need to be any more extreme or creative and, if you decide that you must and haven't completely profiled your operating system's kernel and shell code before implementation to ensure safety from latent dependency bugs (or somehow managed to figure out a way to defend against an army of guys/gals with root privilege easily and with guaranteed low-downtime), may luck be with you. And, if it's not, may you have an understanding superior.

Hopefully, this hasn't confused the issue even further. Whatever the issue was... ;)

Cheers,

, Mike