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

[Raul Miller]

On Thu, Apr 01, 2004 at 10:19:42PM -0500, Sam Hartman wrote:
> Agreed.  Traditionally, however, Unix has not been in the practice of
> being easy to use.  We should be careful, not hidebound.

That depends.

Once upon a time, security wasn't much of an issue, and ease of use for
the casual user was a significant priority.

Of course, at that time, the casual user community was mostly developers
and computer science academics, and we're still fighting a few battles
to close security holes which were left open from back then.

[I'm thinking of stuff like sendmail wizard mode, internet protocols,
and fixed length buffers.]

-- 
Raul

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

[Sam Hartman]

> "Manoj" == Manoj Srivastava <[EMAIL PROTECTED]> writes:

Manoj> On Wed, 31 Mar 2004 14:15:00 -0500 (EST), Sam Hartman
Manoj> <[EMAIL PROTECTED]> 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.

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

[Bdale Garbee]

[EMAIL PROTECTED] (Sam Hartman) writes:

> The problem is fairly simple.  Some of our users actually want to use
> their systems once they get it installed.

 ;-)

> Perhaps when Debian and the FHS originally made this decision, users
> could be expected to simply add themselves to groups if they noticed
> they needed the permissions associated with these groups.  However as
> Debian has gained appeal to a wider audience and as peoples'
> expectations of usability increase,  users want more reasonable
> default behavior.

If we're talking about single-user machines with a graphics card for a console,
then I certainly agree.  We need to be careful to avoid a change that makes
things worse (less secure, etc) for headless systems like servers, though.

> The Redhat pam_console module does seem to do roughly what we want .

The idea of conditionalizing access rights on the basis of whether a user
currently controls "the console" feels to me like exactly the right way to 
approach this issue.  I haven't studied pam_console, and so don't have a strong
opinion on whether it's the right hunk of code or not.

Bdale

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

[Wichert Akkerman]

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

A problem is that is simply isn't possible to do it securely currently,
which is why unices have not done this. The standard attacks are
creatin of sgid shells as mentioned and starting a long-running process
that keeps an open filehandle on a device long after a user has logged
out and another logged in. 

The possible solutions have all been discussed years ago and at that
point we decided to wait until the kernel got a revoke systemcall which
closes all open filehandles on a file. Using that one can chown a device
to the currently logged in user, and chown it back and revoke all open
filehandles on logout.

If we need to choose between chown and group member my vote would be for
chown, for two reasons:

* it is slightly more secure since it does not create the option for the
  users to create sgid executables
* while this does not allow multiple users on a physical machine (it
  breaks if another user logs in on another virtual console) I doubt
  this is a problem for standard machine usage

It is slightly more fragile than group membership though:

* it breaks if a user logs in one two consoles and then logs out on
  one of them since that will generally leave him without access to
  the device
* if the machine crashses, looses power or otherwise shuts down the
  devices will be left with the wrong owner. This can be fixed in a
  boot-time script of course.

Wichert.

-- 
Wichert Akkerman <[EMAIL PROTECTED]>It is simple to make things.
http://www.wiggy.net/   It is hard to make things simple.

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

[Manoj Srivastava]

On Wed, 31 Mar 2004 14:15:00 -0500 (EST), Sam Hartman <[EMAIL PROTECTED]> said: 

> The problem is fairly simple.  Some of our users actually want to
> use their systems once they get it installed.  Particularly, they'd
> like to be able to do things like play sound, access their floppy
> drives and cdroms, etc.  Currently, to do that, you need to be added
> to groups that have access to devices.  I think some of this comes
> from the FHS rather than just decisions internal to Debian.

> Perhaps when Debian and the FHS originally made this decision, users
> could be expected to simply add themselves to groups if they noticed
> they needed the permissions associated with these groups.  However
> as Debian has gained appeal to a wider audience and as peoples'
> expectations of usability increase, users want more reasonable
> default behavior.

> The proposal in bug #166718 and the bugs merged with it is for the
> initial user to be added to some set of groups.  Karl does not like
> this proposal because it only solves the problem for the initial
> user.  That's great until you actually start to take advantage of
> the fact your Debian system is multi-user.

It seems to me that this ought to be local policy. Can you
 explain to me how the proposed solutions take site policy into
 account?  Would it be feasible instead have a simple way of enabling
 one or more users (perhaps a site wide list of users, with exceptions
 for services) to use a specific service?  Would there be security
 issues involved in giving wholesale access to hardware resources?

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

manoj
-- 
Why did the Roman Empire collapse?  What is the Latin for office
automation?
Manoj Srivastava   <[EMAIL PROTECTED]>  
1024R/C7261095 print CB D9 F4 12 68 07 E4 05  CC 2D 27 12 1D F5 E8 6E
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C

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

[Sam Hartman]

Hi.  After discussing the issue together, the shadow maintainer and I
(PAM maintainer) have decided to refer the issue of initial groups for
users to the TC.  This is not one developer asking the TC to overrule
another; Karl and I are in agreement that the issue is bigger than
either of our packages and that Debian should have a consistent
direction on this issue.

The problem is fairly simple.  Some of our users actually want to use
their systems once they get it installed.  Particularly, they'd like
to be able to do things like play sound, access their floppy drives
and cdroms, etc.Currently, to do that, you need to be added to
groups that have access to devices.  I think some of this comes from
the FHS  rather than just decisions internal to Debian.

Perhaps when Debian and the FHS originally made this decision, users
could be expected to simply add themselves to groups if they noticed
they needed the permissions associated with these groups.  However as
Debian has gained appeal to a wider audience and as peoples'
expectations of usability increase,  users want more reasonable
default behavior.

The proposal in bug #166718 and the bugs merged with it is for the
initial user to be added to some set of groups.  Karl does not like
this proposal because it only solves the problem for the initial
user.  That's great until you actually start to take advantage of the
fact your Debian system is multi-user.

Another proposal is to use paM_group to manage these groups.  IF
someone is logging in on /dev/tty[0-9] or :0 or :0.0 or one of the
other console devices, given them audio, cdrom and floppy.  This isn't
really all that desirable either because  it allows  any console user
to permanently gain that group.  In particular, they can create a
setgid executable belonging to that group.

The solution some Solaris environments I'm familiar with use to this
problem is to chown the appropriate devices to the console user.  That
prevents the console user from giving away privileges.  I'm not sure
it's compatible with the FHS, and I'd certainly want buy-in from the
rest of Debian before doing that.  Also, I don't believe we currently
have an implementation of something to do that chowning in
Debian--presumably it would be a PAM module.  I don't have time to
write code to solve this and I don't think Karl does either.


The Redhat pam_console module does seem to do roughly what we want .
IN the past people have objected significantly to adding this module
to Debian for security track record reasons.  I don't know how valid
these objections are.

Thanks for your consideration,

--Sam