[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Debian Wheezy Compromised - www-data user is sending 1000 emails an hour



On Thu, Jan 2, 2014 at 12:24 PM, Bob Proulx <bob@proulx.com> wrote:
> [...]
>  For example if you install squirrelmail it will include
> /usr/share/squirrelmail/**.php files in the package.  Root owns those
> files.  This is good because that prevents any other account from
> being able to modify those files.  That is just long standing good
> design.

Well, you know, I have been trying to work out a way to generate a
user to own each application. Without breaking the ability to update,
etc.

There are people who want to combine /bin, /sbin, /usr/bin, and
/usr/sbin. I want to go the opposite direction, to put each
application in its own subdirectory under /app or something, and put
links to the provided apps in /bin/<user>/bin or something, so that
each user can have his own chrooted /bin with only the apps that user
should be allowed to use.

And I want to allocate an application-specific user to own each
application. Maybe more than one. Separate from the user(s) allocated
to run the daemons and servers for the application.

To take advantage of such a setup, each application would need to
supply a set of standard update routines, and update itself when
directed to by the system, I suppose. Otherwise, admin users would
have to sudo or su to root anyway, which I suppose is one of the
reasons no one has been so, ehh, fanatical? about it yet.

I wonder whether we could design a set of default update calls for
such a system. It's a project to keep on the back burner, I suppose.

>> It is a very bad idea to use the root user to do such mundane
>> things.
>
> System administration is hardly mundane.  It is often misunderstood
> (as in this thread) but very important work.
> [...]

I think the point is that certain configuration files could well be
owned by a special purpose user.

Say I'm building a content-management system called "zerostone" and it
provides a web-facing configuration mechanism. I'd set it up so that
the user "admst0ne" owned the configuration files that could be
accessed from the web, and the server that provides access to the
configuration files would maybe run as admst0ne.

The non-web-facing configuration files would be owned by "zishi", and
all human users who are allowed to log in to a regular shell and edit
the configuration files would be members of the "zishi" group, or be
allowed to sudo to "zishi" by rules in the /etc/sudoers.d directory.

Or something like that.

Purely hypothetical, of course.

-- 
Joel Rees
Logic kills. How logical do you want to be?


Reply to: