Did Ya Get Hacked

Or somebody fried your unix permissions, maybe?

I don't often pay too much attention to that -rwxrwxrwx stuff or the mysterious set uid, set gid, and sticky bit stuff. But when I do, I must re-explain to myself the translations between the chmods and the ls's. I can get particulary bewildered when I start to see oddball stuff like drwxr-sr-x and drwxrwxrwt. Apparently, the latter is normal for /tmp. However, I doubted that the former was normal for /usr/bin.

I began to notice that some recent files in /usr/bin showed up owned by 2011 and group 2000. That didn't seem right. The first word that came to mind was hacked. I doubted it, but the hunt was on. First I did a 'ls -ltr /usr/bin' to see that it was just some recent files that got that way. But why? Then I tried 'find / -xdev -uid 2011' and it listed the whole /usr/bin directory. That's not right. Not only did /usr/bin have that funny setgid bit set, but it was owned by 2011. And the same thing had happened to /usr/share.

To make a long story short, a script named install "(C) 2003 Till Kamppeter," in the foomatic-filters-ppds package installed a bunch of files user/group 2011/2000 and also made /usr/bin and /usr/share user/group 2011/2000 and it set the setgid bits. So this was not a hacker, but I'd say a real foo-bar. All the files in that particular foomatic-filters-ppds package had the user/group as 2011/2000 and the setgid bit was set on its 2 subdirs bin and share. The script copies those subdirs into place using cp -ax bin share $destdir$prefix. That's what did the job on my filesystem. (cp -dR would really have been better). Looking again at the foomatic website, I notice that the foomatic-filters-ppds package now only exists hidden under an "oldstuff" directory. Perhaps they thought "oops", or maybe they found yet another way to make linux printing more complicated to install.

Fixing it becomes a royal PITA (major annoyance). With chown I can get the user and group put back to reasonable values. But I'm still messing around with the setguid bit (?why did they do that?). On a backup, I can see that both /usr/bin and /usr/share used to be drwxr-xr-x with user and group root and root -- and no setgid bit. I have no clue what's supposed to really be setguid. I don't quite understand why things installed since "foo-bar" acquired the setgid and user/group 2011/200. If possible, I'll try to straighten it out manually. I'm not going to leave it as it is because of all the security hubbub about things being setuid or setgid.

I think this can find the setuid setgid ones:
find / -xdev -perm +ug=s -exec ls -ldb {} \;

Knowing that this will probably happen again sometime, I did try in vain to find a good permissions translator. None found.

So I started working on this script: cvbase

As it stands, it can take the -rwxrwxrwx part of 'ls -l' and print a chmod number.

For instance:
cvbase -ls rwsr-xr-x
prints 4755

It can take ls -l piped to it like:
ls -l /usr/bin/sudo | cvbase -ls
prints 4111


It started out as a calculator to convert a number from ibase to obase.

The general format is:
cvbase o-i num num num ...
o is obase (optional)
-i is ibase (optional)
but either o and/or -i must be specified
defaults to 10
o and/or i can be ls, 2-32

cvbase -16 FF
prints 255

cvbase 16 256
prints 100

cvbase -ls drwxr-sr-x
prints 2755

cvbase 2-8 2 7 5 5
prints 10 111 101 101
which is the same as drwxr-sr-x

But it's hard to see because ls adds things up.
The bits are really like:
-s- rwx r-x r-x
010 111 101 101

At least that's how it was explained in this post about Unix File Permissions

The "base" of "ls2" is an attempt to understand these setuid/gid and sticky things:
cvbase ls2g1 2755
prints -s- rwx r-x r-x

In the above, the setuid/setgid/sticky tuple has the setuid bit - (or 0 or off), the setgid bit s (or 1 or on), and the sticky bit - (or 0 or off).

Anyway, I can say:
cvbase 8-2 111 101 101
which says convert to base 8 from base 2, the numbers 111 101 101
and it prints 7 5 5
(note the spaces in this example)

There can be a 'd' which stands for "dump the input' in either ibase or obase. Sometimes, it might be handy to see the result side by side with the corresponding input.
cvbase -2d 111 101 101
prints 7 5 5 111 101 101

There can be a 'g' which stands for "group by" in either ibase or obase. If the 'g' is followed by a number, that's how many digits in a group.
So, instead of the above example, the same thing can be done with:
cvbase 8-2g3 111101101
and it prints 7 5 5

If the last group is too small, its still ok, so:
cvbase 8-2g3 11110110110
prints 7 5 5 2

But the special "base" of "ls" ignores the 'g' part and expects a "one thing" format:
cvbase ls 4755
or
cvbase -ls rwsr-xr-x

The "base" of "ls" got that way, and anyway, when thinking of chmod or ls -l, the "it" is a single string of numbers or characters.

This doesn't help enormously in fixing the problem, but if I decide to change these permissions, I will have the option of calculating the octal digits for chmod instead of having to unfigure and refigure the funny looking rwxr-sr-x notation to decide what command to type.

Other uses:

Playing with colors often calls for converting between rgb numbers in decimal and hex color codes.
For a long time, I wanted to see hex values of named colors in rgb.txt:

cat /usr/share/X11/rgb.txt | cvbase 16d \
       | awk '{printf "%02s%02s%02s %s %s\n", $1,$2,$3,$7,$8}' \
       | grep -i " royalblue\|dark.*red"

prints:
4169E1 RoyalBlue
4876FF RoyalBlue1
436EEE RoyalBlue2
3A5FCD RoyalBlue3
27408B RoyalBlue4
8B0000 dark red
8B0000 DarkRed
(Note the %02s is needed to put leading zeros to make valid hex codes on some.)

At least I didn't get hacked, but I'll probably need to uninstall back to the "foo-bar" point in time and reinstall from there (Fabulous!)