Re: Login shell (was: Small Bug)
On 17 Mar 2000, Niels Möller wrote:
> > Make the files world-readable and have a anonymous guest-account on your
> > system - alas, you have exactly the same effect.
> Not if I want to have some files which I want to be readably by any of
> the ordinary users, but not by guests. You could say that I have to
> use something like ACL:s to do that. But I think that guests are such
> a special case that it is reasonable to let the system be aware of the
> distinction between users and guests (more on this below).
Well, yes, in that case. Every unix system I've admin'ed to date has had
a "default group" for all users when you create them: "users" (in HP-UX &
Linux) or "group" (in SCO, but then I hate SCO). Not that I'm in the
habit of creating guest accounts, but should I need to, I'd simply create
the user "guest" and *not* add that user to *any* group. Then they'd only
have access to things on the filesystem that are explicitly world readable
or executable, and nothing else.
> > The non-logged-in permissions will have to be set by the package
> > maintainers, but if we really need that functionality offered by the default
> > Debian system, we could just as well make a more complex group system part
> > of the policy.
> I think you will find that quite difficult. It would take a draft of
> such a system to convince me otherwise.
Personally, I'm not sure about the whole idea of an additional byte of
permissions that so many packages will have to be rewritten to support.
This may just be me, but I think it's more work to use hurd-specific tools
to play with these additional permissions, than it would be to have proper
permissions on your filesystem anyway. if the admin is smart about
permissions for other/world access, then a "guest" user who is a member of
no group (i.e., must rely on things which have world-access permissions)
can't really get into anything they shouldn't.
(woudl that be the same as the "nogroup" group on some systems, and would
that then introduce a paradox into the universe? How can you be a member
of no group and a group called "nogroup" at the same time?)
Now, what I want to know, is can you deny, say, read and execute access to
/etc for the not-logged-in user, and still have someone able to log in
from the login shell? If that's the case, then I think it's a neat idea,
but I'd really rather see the development of a filesystem that supports
ACL's than the hack of grabbing another byte for permissions specific to
the not-logged-in user. I'd even help, if I knew anything about
filesystems.
> Well, I don't see it as a big problem if just some of the file
> managers know about the extra bits. It's quite important that tools
> like find know about them, though. BTW, you have a similar situation
> on systems with ACL:s, but I don't think that causes any big problems.
This is very true... However, I think the benefits outweigh the problems,
when you add ACL's to the feature set instead of the not-logged-in user
permission bits.
a) you can specifically and explicitly allow or deny access types on a
per-group or per-user basis (thereby negating the need for the
not-logged-in user permission bits)
b) You can do (a) for any user and any group an any file, if the
filesystem itself supports ACLs.
ACL's are one of the few things I liked when I used NT. (it's just
everything else I hated =)
> Ordinary users are individuals (or special system services), that are
> *identified* by their user name or uid. So it is reasonable for tools
> to assume that to be true for all users. The guest account violates
> this principle, so whenever a tool makes this assumption, the guest
> account becomes a security problem.
This is more a problem with the tools than with the user/group vs. the
not-logged-in user problem.
Even so, I'm not entirely sure how you could have a guest account without
having an entry for it in /etc/passwd... So, there *would* be identity
information in /etc/passwd for the tools to use.
Again, though, these problems could better be solved by ACLs, where you
could say everybody except "guest" can do x, y and z, but "guest" can do
w.
> Do you know of any reasonably secure Unix system that has an enabled
> guest account? I don't but perhaps I'm just ignorant. I believe it is
> too much work to make a guest account secure to make it a serious
> alternative.
But, then, how different is the login user? there's an entry in
/etc/passwd, and unless the admin goes out of his way to change the
not-logged-in permissions, the person at the login> prompt can do anything
a guest user in another unix could.
The more I think about this, the more it seems like an issue of symantics,
rather than a real security issue. I think we should agree that it can be
done both ways, with each way having it's benefits and drawbacks. You
like one, I like another. I'd prefer a third (ACLs).
--
Gregory Ade <gkade@bigbrother.net>
Find PGP public key at http://www.pgp.com (Key ID 0x63B57600)
#include <standard/disclaim.h>
procmail(1) is your friend.
Reply to: