Last modification for user privacy

Continuing with the privacy on a public unix system theme, one other binary that easily allows users to gain information about another user is last. Not only does last show the host or ip of a user as in the case with w and who, but last also shows when a user has logged on, allowing someone to learn information about usage patterns that most people would prefer to keep to themself.

The easiest way to avoid people seeing what they should not with last would be to stop people from using it by simply changing the permissions, however, some people like to see when they last logged on, and to make sure their account was only used by themselves. For these reasons, and several others, last is important. To that end, I decided to modify the last binary to make it so that a user can use it as normal, except that it will only give information about that user unless they are in group 0 (wheel), which on a freebsd machine is the users who are allowed to su to root.

To implement this, modifications of the want function were required to take into account both whether a user is in group wheel, and if not, what their login is, to ensure they see only that information.

int
want(bp)
    struct utmp *bp;
{
      
    struct passwd *pw;
    int id;
    gid_t gidset[5];
    int i;
    int groups;
    int access=0;
    ARG *step;

    id = getuid();
    pw = getpwuid(id);
    groups = getgroups(5, gidset);
    for (i=0; i<=groups-1; i++)
        if (gidset[i]==0) access=1;
    if (getgid()==0) access=1;

    if (!strcmp(bp->ut_name,pw->pw_name) || access==1) {
        if (!arglist)
            return (YES);
        for (step = arglist; step; step = step->next)
            switch(step->type) {
                case HOST_TYPE:
                    if (!strncasecmp(step->name, bp->ut_host, UT_HOSTSIZE))
                        return (YES);
                    break;
                case TTY_TYPE:
                    if (!strncmp(step->name, bp->ut_line, UT_LINESIZE))
                        return (YES);
                    break;
                case USER_TYPE:
                    if (!strncmp(step->name, bp->ut_name, UT_NAMESIZE))
                        return (YES);
                    break;
            }
    }
    return (NO);
}

An important thing to remember in UNIX security is that It Is Usually Not That Simple. You have to consider the implications of everything; if you want to keep someone from doing something, you can not do it unless you consider every possible way they could have of doing said thing.

Yes, the last modification above will help user privacy, and keep most users from seeing the other users' info. But if i were a user on Andukar's box, and i really wanted to see someone else's last information, i could just say:

cat /var/log/wtmp|perl -e 'undef $/;$_=<>;s/[^\w\.-]+/\n/sg;print $_;'|less

Which is, as it happens, exactly what i did when i had to use last on a box where the binary was broken! Try it.

You've modified who or w for user privacy, sure, but who says they have to use your mods? What's to keep users from compiling their own who or w or finger binaries, or talking to fingerd themselves, or reading the data files fingerd uses? (Note: That is an honest question-- for all i know, modifying who and w the way described in those other nodes may be sufficient. I do not know exactly how who and w work, or even if bsd uses fingerd or what.)

You have to keep cause and effect in mind, and if you close off an interface make damn sure you close off the stuff that makes that interface work as well. In fact, it's usually better to close things off as close to the source as possible-- say, instead of restricting who or w, restrict the source who and w get their information from. (This may, of course, not be possible) (assuming BSD uses fingerd, of course) so that there are as few moving parts as possible.

Now, of course, for all i know, andukar has set up his box in such a way as /var/log/wtmp is only accessible through last, meaning his setup is completely secure, but if he has i don't know how he did it, and i do know that such a setup will not be the default in your average *n?x setup.

Never trust a quick-fix; more often than not you are merely leading yourself into a sense of false security. Like the windows nt administrator at our school who restricted the users to only be able to run a handful of approved programs, causing huge problems for those of us who urgently needed to be able to run a non-approved program-- for example, Calculator-- but then did absolutely NOTHING to prevent a user from taking a non-approved program and renaming it to notepad.exe, magically making it one of the programs on the approved list. (Restrictions != security!)