Cleaning up the users and locking down the shells in /etc/passwd
ubuntu.com at mattalexander.com
Tue Sep 27 13:03:52 UTC 2011
On Mon, Sep 26, 2011 at 3:28 PM, Bear Giles <bgiles at coyotesong.com> 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.
> On Mon, Sep 26, 2011 at 4:05 PM, Matt Alexander <
> ubuntu.com at mattalexander.com> wrote:
>> On Sat, Sep 24, 2011 at 9:48 AM, Colin Watson <cjwatson at ubuntu.com>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
>>> > and instead rely on the application being installed to create the
>>> > user if needed? Most of the users appear to be historical remnants
>>> > 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
>>> > 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
>>> (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=274229). However,
>>> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=184979 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
>>> 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.
>>> Colin Watson [cjwatson at ubuntu.com]
>>> Ubuntu-devel-discuss mailing list
>>> Ubuntu-devel-discuss at lists.ubuntu.com
>>> Modify settings or unsubscribe at:
>> Ubuntu-devel-discuss mailing list
>> Ubuntu-devel-discuss at lists.ubuntu.com
>> Modify settings or unsubscribe at:
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Ubuntu-devel-discuss