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

Re: Bits from the release team: the plans for etch

* Thomas Bushnell BSG (tb@becket.net) wrote:
> We aren't talking about log files created by the package, but by the
> sysadmin.
> What if the sysadmin has taken the sensitive log and squirreled it
> away, saving it for future reference?  Is that no longer a supported
> thing? 

One would hope he'd chown it too.  Indeed, *most* log files are owned by
root/adm anyway.  I'd actually be happier if that could be enforced,
thus this concern about log files actually goes away, not that I think
it's really a legitimate concern anyway.

> > Additionally, this is *not* a problem with the orphaning of the file,
> > it's a problem with the reuse of a previously-used uid.  I could see
> > adding a system to track previously-used uids and not reusing them.  I
> > don't believe using passwd for that (and keeping unused accounts in
> > passwd/shadow/group/gshadow/etc) is appropriate.  
> Why?  What purpose is served by segregating the information?

Not keeping around unused accounts, that may have been set up as capable
of being authenticated to in the past by the admin for whatever reason.
Not to mention that it's leaving a hell of alot more around than is
necessary.  If you don't want to reuse ids, then have a nice simple
system that prevents reusing them, don't leave cruft around to get in
the way to try and prevent it.

What happens when the piece of software that created the userid
initially is reinstalled?  What if the attributes for the user changed,
possibly to deal with some security flaw in the original configuration?
What if there were files still on the system that the new installation
*shouldn't* have access to?

Even better, what if that crazy admin created orphaned files to *begin*
with, and didn't put a user in /etc/passwd, whoops!  We create a new
user with that userid, oh no, big security hole...



Attachment: signature.asc
Description: Digital signature

Reply to: