Cleaning up the users and locking down the shells in /etc/passwd

Matt Alexander at
Tue Sep 27 13:03:52 UTC 2011

On Mon, Sep 26, 2011 at 3:28 PM, Bear Giles <bgiles at> wrote:

> Matt, why not create a hardening package? Just write a script that scrubs
> /etc/passwd and /etc/group and then create a small package that runs it once
> (in postinst). I would also install it in, e.g., /etc/cron.daily so it's
> rerun periodically. I haven't kept track of existing hardening packages
> but I wouldn't be surprised if somebody else has already done this.

I've used Bastille in the past, for example, but I think most users would
prefer that Ubuntu is already hardened by default.

> P.S., if you want to have fun with package installation failing try
> mounting /tmp as noexec. It's easy to fix - if you know how to do it. If not
> you'll bang your head against the wall for hours while you're trying to
> figure out why installations are failing.
> bear
> On Mon, Sep 26, 2011 at 4:05 PM, Matt Alexander <
> at> wrote:
>> On Sat, Sep 24, 2011 at 9:48 AM, Colin Watson <cjwatson at>wrote:
>>> On Thu, Sep 22, 2011 at 04:33:00PM -0700, Matt Alexander wrote:
>>> > Would it be possible to remove the vast majority of users from
>>> /etc/passwd
>>> > and instead rely on the application being installed to create the
>>> specific
>>> > user if needed?  Most of the users appear to be historical remnants
>>> that
>>> > have been carried over from release to release.
>>> For almost everything, and certainly for the overwhelming majority of
>>> new entries, we do exactly as you say.  However, I (as base-passwd
>>> maintainer) will not remove entries from the global static list unless
>>> there is a very compelling reason to do so beyond cleaning up cruft;
>>> packages are entitled to assume that they are present without declaring
>>> any particular dependency and there's no reasonable way to know what
>>> removing such entries would break.
>> I end up modifying the passwd/group files on my computers for auditing
>> purposes and to ensure that the only accounts on the system are required
>> accounts.  Removing cruft seems like a perfectly valid reason.  In 10 years
>> will Ubuntu still have a uucp user and a news user and an irc user?  Seems
>> silly.  Let's clean things up and keep it to just the accounts that must be
>> there.  We can then easily fix packages that wrongly assumed that their
>> particular user would be always be there.
>>> In any case, there are only 18 entries in the global static list
>>> (/usr/share/base-passwd/passwd.master), and even without thinking about
>>> it too hard I know that at least four or five are still in use and
>>> probably more, so there's not that much to be gained.  All other system
>>> entries in the passwd file are created dynamically by applications.
>>> Since I took over base-passwd in 2002, I have added no new global static
>>> users and only two new global static groups, the last of which was in
>>> 2004.
>>> > In addition, for users in the passwd file that must be there, could you
>>> > please set their shell to /usr/sbin/nologin?
>>> Yes, I would like to do this eventually
>>> (  However,
>>> has to be fixed
>>> first, otherwise everyone will have their upgrades interrupted by a
>>> non-debconf prompt.  I haven't had time to work on #184979 in quite a
>>> number of years, and to the best of my knowledge nobody has ever
>>> contributed a patch for it; I'd be happy to review one if somebody did
>>> so.
>>> The one wart here is that using /usr/sbin/nologin will break anything
>>> that runs commands as one of those users using the 'su' command.  This
>>> isn't theoretical; one of my packages used to do so some years ago,
>>> although it now uses start-stop-daemon instead.  The breakage is
>>> probably worthwhile, I'll admit, but I can't say that there would be no
>>> problems with changing those users' shell since there's been such a long
>>> time for packages to get used to it being /bin/sh.
>>> Cheers,
>>> --
>>> Colin Watson                                       [cjwatson at]
>>> --
>>> Ubuntu-devel-discuss mailing list
>>> Ubuntu-devel-discuss at
>>> Modify settings or unsubscribe at:
>> --
>> Ubuntu-devel-discuss mailing list
>> Ubuntu-devel-discuss at
>> Modify settings or unsubscribe at:
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the Ubuntu-devel-discuss mailing list