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

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

Stephen Frost wrote:
* Andreas Barth (aba@not.so.argh.org) wrote:
* Stephen Frost (sfrost@snowman.net) [051026 20:13]:
This is just patently false, as has been pointed out elsewhere.
security hole, exactly, is created by orphaning a file?
Well, if some process (maybe within the package) creates a private log
file that contains sensitive information, and this log file can later
be read by a process with much less privileges, this is usually
considered as security relevant issue.

Except log files are supposed to be removed and I don't know of any
actual case of this happening 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.  It would seem enough
to me, at least, to keep an ever-increasing counter where the current
value is the next available uid.  This could be reset if it reaches the
max, or an error presented to the user about it or some such.

I'm not convinced that's necessary but I could see it being something
reasonable to do.  Just leaving around unused accounts isn't reasonable.

one (more interesting, maybe) approach could be using some automated method to see what are _every_ _single_ user-id created by our packages (not very difficult) and collecting them in a single package, with UNIQUE uids (so www-data will be "nnnn", no matter what): this way we can purge users at --purge time.


Reply to: