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

Re: Referring bug #166718 and the initial groups issue to the TC



>>>>> "Manoj" == Manoj Srivastava <srivasta@debian.org> writes:

    Manoj> On Wed, 31 Mar 2004 14:15:00 -0500 (EST), Sam Hartman
    Manoj> <hartmans@debian.org> said:
    Manoj> 	It seems to me that this ought to be local policy. Can
    Manoj> you explain to me how the proposed solutions take site
    Manoj> policy into account?  

Well, adding the initial user to groups does not take site policy into
account at the present time, because there is not really a point in
the current install to give a system a site policy before the initial
user is created.  If a local administrator wishes to enforce site
policy they can either decline the install's option of an initial user
or remove the initial user from groups.

A pam_group approach would presumably involve having changes to the
default /etc/security/group.conf.  That file is a configuration file
and by its nature an expression of site policy; admins wishing to
enforce a different policy could modify that file.  Debian policy
requires that changes to a configuration file be preserved.


The pam_console approach would presumably live in
/etc/security/console.* and /etc/pam.d/common-session.  Those files
are either conffiles or configuration files and as such are
expressions of policy.



    Manoj> Would it be feasible instead have a
    Manoj> simple way of enabling one or more users (perhaps a site
    Manoj> wide list of users, with exceptions for services) to use a
    Manoj> specific service?  

I cannot think of a simple design for this in 30 seconds that seems to
meet the needs of users to have more friendly defaults and that would
work across a wide range of configurations.  However the really good
answers rarely come from 30 seconds of thought.


    Manoj> Would there be security issues involved
    Manoj> in giving wholesale access to hardware resources?

To everyone?  Yes.  As an example, giving someone access to sound
devices might turn a Debian system into a hidden microphone for the
use of spies.  Giving access to removable storage might allow a remote
user to gain access to a PGP key someone had on removable USB storage.

But for a large class of machines--single user workstations--giving
the console user or primary machine owner access to hardware resources
is desirable and consistent with reasonable security policies for that
class of machine.  Again, we are discussing defaults, not fundamental
changes to what is possible with the Debian security architecture.



    Manoj> 	Traditionally, UNIX has not been in the practice of
    Manoj> automatically adding users to groups, and I think we need
    Manoj> to be careful if we decide to break from universal
    Manoj> practice.

Agreed.  Traditionally, however, Unix has not been in the practice of
being easy to use.  We should be careful, not hidebound.



Reply to: