[DSE-Dev] [libsemanage] Also check for the uppoer bound on user ids in /etc/login.defs

[selinux at udmvt.ru]

Sorry for breaking into your conversation,
but it was me who posted the bugreport.

(My name is Alexey G. Shpagin, I am system administrator and I am posting
here for a first time.)

On Thu, Jan 08, 2009 at 08:33:54AM -0600, Manoj Srivastava wrote:
> Hi,
> 
>  [Trimming the patch and early discussion]
> 
> On Wed, Jan 07 2009, Daniel J Walsh wrote:
> > Manoj Srivastava wrote:
> >> On Wed, Jan 07 2009, Stephen Smalley wrote:
> >>> As Dan pointed out, the UID_MAX value in login.defs is only used by
> >>> useradd, and is not even strictly enforced (useradd -u 60002 john works
> >>> just fine).  In an environment with a large number of users and a global
> >>> user database, you can certainly exceed 60000 users or you may even
> >>> happen to generate your uids in a manner that happens to put them all in
> >>> the upper part of the uid space.  There are real systems with uids >
> >>> 60000 for real users, yet the login.defs UID_MAX value has not been
> >>> changed on such systems because it is irrelevant and it isn't enforced
> >>> by anything.  So this patch would change behavior of libsemanage on such
> >>> systems in an undesirable manner.  And it wouldn't help with cases like
> >>> oracle where the pseudo user is added via useradd without any specified
> >>> uid at all.

I should note, that useradd -u 52 john works not even worse. What about the
systems, that have legal user uids below UID_MIN?
UID_MIN is also not enforced anywhere except the automatic uid generation in
useradd or maybe some custom pam modules (don't know of any).

> 
> >>> I think Dan's earlier posting gets to more of the fundamental problems
> >>> with genhomedircon's heuristics for finding home directory locations,
> >>> and we need to address his points if we want it to work in general.
> 
> >>         Fair enough. In that case, I would like to point out that the
> >>  current situation of only checking UID_MIN is causing actual problems
> >>  right now on real user systems, and making genhomedircon to incorrectly
> >>  guess where home directories exist.
> 
> >>         I'll treat this as an imperfect workaround until we fix
> >>  semodule, and then I'll just revert the patch for Debian systems.
> 
> > What does the passwd entry that it is getting fooled by look like?  Does
> > the account really need a real shell?  IE Do people actually login to
> > the home directory?
> 
>         I do not have passwd data from the machine in question, though I
>  can ask. What I do have are the results of fixfiles relabel / :

The accounts were created not by hand, but by (pre|post)install script of qmail
package. That script is not perfect (and already have some minor issues), but
still I'm not sure if adding system users with /bin/sh was done by mistake
or for some reason, yet to be checked.
In the case you are still curious, here they are:

alias:x:64010:65534:qmail alias,,,:/var/qmail/alias:/bin/sh
qmaild:x:64011:65534:qmail daemon,,,:/var/qmail:/bin/sh
qmails:x:64012:64010:qmail send,,,:/var/qmail:/bin/sh
qmailr:x:64013:64010:qmail remote,,,:/var/qmail:/bin/sh
qmailq:x:64014:64010:qmail queue,,,:/var/qmail:/bin/sh
qmaill:x:64015:65534:qmail log,,,:/var/qmail:/bin/sh
qmailp:x:64016:65534:qmail pw,,,:/var/qmail:/bin/sh

What I can't keep in mind anymore is the way I want it to be:

 1. Every nontrivial behavior (you call it heuristics) of libsemanage must be
    documented prior deployment (and documentation be referenced from at least
    semanage(8) man page). It looks like libsemanage already have enough
    heuristics and deserves it's own manpage in (8).
      I think, that the way of dependency of something perceived as component
    of selinux (that stated to have no relation to UNIX uids and accounts) on 
    records from /etc/passwd is pretty nontrivial. Something tells me, that it
    should somehow map UNIX accounts to selinux labels, but I can only guess about
    what is the exact process.
      Even more, hidden dependency on some_but_not_others config parameters from
    logins.defs is just the example of nontrivial and counterintuitional behavior.
    (It will be easier for me (without need for sources) to track down the issue if
    UID_MIN were not used too, or UID_(MIN|MAX) were used both).

 2. It is hard for me to determine, what are the login.defs' UID_MIN and UID_MAX for,
    and especially what they are not.
    The (only|best) way they can be used is during the initial configuration of
    libsemanage by postinstallation scripts that create SEPARATE configuration
    file for libsemanage and copy there all the needed settings from whatever
    you want. Maybe asking the administrator some questions. Also allowing him
    to reconfigure that again at his request.
    
    Only in separate configs should exists that UID_MIN, optional UID_MAX (and maybe
    also useful UIDS_EXCLUDE, USERS_EXCLUDE, and even better - GIDS_EXCLUDE,
    GROUPS_EXCLUDE) that will affect applications deploying libsemanage.
    They should be documented also, but if not, it will already be easier to guess
    their effect if they will live inside something like
    /etc/selinux/libsemanage/automatic_accounts_mapping.conf
    (well, at least easier for me).
    And it will be natural for [new] system administrator, who changed /etc/login.defs
    in some way, not to hope that it will affect selinux components in some other way.
    It will be natural for him to make an attempt to find corresponding selinux
    configuration parameters to correct them accordingly
    (if that seem appropriate for him).

Still I wonder whether some other selinux components (in other libraries) depend on
some old (more traditional than SELinux) UNIX configuration files in some way...

Consider this as a subjective opinion of a mediocre system administrator, that have
to deal with your creatures.
Thanks for your time and many thanks for that creatures.

--
Alexey G. Shpagin
System administrator
Volga Telecom