Re: crontab and editors (was Re: Editor Priorities)
On Mon, May 13, 2002 at 10:54:44AM -0500, Manoj Srivastava wrote:
> >>"Matt" == Matt Zimmerman <mdz@debian.org> writes:
>
> Matt> After the edit is complete, crontab (the privileged parent
> Matt> process) reads the resulting file in order to write it into the
> Matt> crontabs directory. The point is to avoid letting users trick
> Matt> crontab into reading arbitrary files and writing them into the
> Matt> user's crontab, where the user can then read them.
>
> How on earth are you going to prevent that? crontab /some/file
> already allows one to replace my own crontab with something else. Or
> are you claiming that crontab reads, parses, and sanitizes any file
> presented? In which case, once the users symlink is read, do the same
> sanitation.
No, but crontab swaps saved/effective UID before reading a file presented on
the command line, so it is read with the privileges of the user. This
technique could be applied to the edit function as well; that would be
another approach. The comments say:
/* we still have the file open. editors will generally rewrite the
* original file rather than renaming/unlinking it and starting a
* new one; even backup files are supposed to be made by copying
* rather than by renaming. if some editor does not support this,
* then don't use it. the security problems are more severe if we
* close and reopen the file around the edit.
*/
But I don't think that closing and reopening the file presents any
insurmountable evil. As long as the file is opened with the permissions of
the user, and the input is untrusted, it shouldn't be a problem. I wonder
what they were thinking of here.
> I think this is going way beyond what is required; a user can
> always present any file to crontab, and a suer can easily destroy any
> files they have write access to. Preventing a cracker from tricking a
> user into destroying their own files ought to bge the goal here.
As I mentioned, there are two goals. One, to prevent one user from
attacking another by finding a way to place data in the target user's
crontab, and two, to securely allow the user to present the crontab data to
root. Maybe there is a secondary goal of trying to prevent the user from
using an editor with a race condition, but that shouldn't be crontab's
responsibility in my opinion.
--
- mdz
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: