Permissions on crontab..
Why is crontab suid root? I say to myself "To update /var/cron/tabs/ and to signal cron". Could crontab run suid 'cron'? If those are the only two things it needs to do, run cron as gid 'cron' and make /var/cron/tabs/ group writable by 'cron'. -- Michael Bacarella <[EMAIL PROTECTED]> Technical Staff / New York Connect.Net, Ltd Daytime Phone: (212) 581-2831 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Permissions on crontab..
On Wed, Jan 17, 2001 at 10:45:57AM +, David Malone wrote: > > True - but I'd say it provides a false sense of security, which > might be more damaging than the extra security provided against > read-only exploits in crontab. That's silly. Group tty can be leveraged to provide more privilege, but that doesn't mean write(1) should be setuid root, or that having write(1) setgid tty provides a false sense of security. I think that the proposed change would be a good idea, and that it's consistent with write(1) and other uses of setgid. -- Ben 220 go.ahead.make.my.day ESMTP Postfix To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Permissions on crontab..
On Thu, Jan 18, 2001 at 01:07:35AM +, void wrote: > > True - but I'd say it provides a false sense of security, which > > might be more damaging than the extra security provided against > > read-only exploits in crontab. > > That's silly. Group tty can be leveraged to provide more privilege, > but that doesn't mean write(1) should be setuid root, or that having > write(1) setgid tty provides a false sense of security. > > I think that the proposed change would be a good idea, and that it's > consistent with write(1) and other uses of setgid. Ideally, crontab wouldn't be suid/gid _anything_ and users own their own crontab file, but perhaps I've said too much. :) -- Michael Bacarella <[EMAIL PROTECTED]> Technical Staff / New York Connect.Net, Ltd Daytime Phone: (212) 581-2831 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Permissions on crontab..
On Wed 2001-01-17 (20:43), Michael Bacarella wrote: > On Thu, Jan 18, 2001 at 01:07:35AM +, void wrote: > > > > True - but I'd say it provides a false sense of security, which > > > might be more damaging than the extra security provided against > > > read-only exploits in crontab. > > > > That's silly. Group tty can be leveraged to provide more privilege, > > but that doesn't mean write(1) should be setuid root, or that having > > write(1) setgid tty provides a false sense of security. > > > > I think that the proposed change would be a good idea, and that it's > > consistent with write(1) and other uses of setgid. > > Ideally, crontab wouldn't be suid/gid _anything_ and users own their > own crontab file, but perhaps I've said too much. :) They do own their own crontab file. The setgid is for adjusting the modification time on the crontab directory, to signal to cron that there has been a change. Neil -- Neil Blakey-Milner [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Permissions on crontab..
> They do own their own crontab file. The setgid is for adjusting the > modification time on the crontab directory, to signal to cron that there > has been a change. I think there may be a neat way of dealing with all of this stuff using unix domain sockets with credential and discriptor passing. It wouldn't require crontab to be suid at all, but would still leave the directoires with their current permissions. I'll try to test it if I have time. David. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Permissions on crontab..
> "Michael" == Michael Bacarella <[EMAIL PROTECTED]> writes: Michael> Ideally, crontab wouldn't be suid/gid _anything_ and Michael> users own their own crontab file, but perhaps I've said Michael> too much. :) Where, exactly, would you store the users crontab file? It can't go in their home directory. Consider a machine with 1 accounts, and all the home directories NFS mounted via amd. Imagine what happens the first time cron scans for file modtimes. (Which it has to do unless it has sole control over the users crontab file, which it doesn't in this scenario.) You can't use a 1777 directory, since that lets others DOS your ability to create a crontab (even though the rogue file they dropped in wouldn't be run by a reassonable cron). I like the idea, but please show us a working design. --lyndon To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Permissions on crontab..
Michael Bacarella wrote: > Why is crontab suid root? It has to run jobs as the correct user and must be able to setuid accordingly. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Permissions on crontab..
In the last episode (Jan 17), Greg Black said: > Michael Bacarella wrote: > > Why is crontab suid root? > > > > I say to myself "To update /var/cron/tabs/ and to signal cron". > > > > Could crontab run suid 'cron'? > > > > If those are the only two things it needs to do, run cron as gid > > 'cron' and make /var/cron/tabs/ group writable by 'cron'. > > It has to run jobs as the correct user and must be able to setuid > accordingly. Not quite. As far as I can tell, crontab is setuid root for the sole purpose of being able to write to /var/cron/tabs. Cron checks the timestamp on the directory every minute, so crontab doesn't have to signal it for changes to get noticed. If you're paranoid, you can probably "chgrp cron /var/cron/tabs" and make crontab setgid cron without any ill effects. Cron itself must stay setuid root, of course, so it can run user crontabs as that user. Or it might need to be setuid for some other reason, since OpenBSD runs their crontab setuid root, and they usually are pretty security-paranoid. -- Dan Nelson [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Permissions on crontab..
Dan Nelson wrote: > In the last episode (Jan 17), Greg Black said: > > Michael Bacarella wrote: > > > Why is crontab suid root? > > > > > > I say to myself "To update /var/cron/tabs/ and to signal cron". > > > > > > Could crontab run suid 'cron'? > > > > > > If those are the only two things it needs to do, run cron as gid > > > 'cron' and make /var/cron/tabs/ group writable by 'cron'. > > > > It has to run jobs as the correct user and must be able to setuid > > accordingly. > > Not quite. As far as I can tell, crontab is setuid root for the sole > purpose of being able to write to /var/cron/tabs. Cron checks the > timestamp on the directory every minute, so crontab doesn't have to > signal it for changes to get noticed. Previously, I wrote a bit faster than is good. There are indeed cron implementations where crontab signals cron, and they must be setuid root. However, as noted above, that's not the case with the current FreeBSD implementation. > If you're paranoid, you can > probably "chgrp cron /var/cron/tabs" and make crontab setgid cron > without any ill effects. Cron itself must stay setuid root, of course, > so it can run user crontabs as that user. At least I was not the only person to write hastily. It is not normal for cron to be setuid (and it is not on any BSD machine that I can check right now). It must be run by root, but that is accomplished by starting it from /etc/rc at boot time (or by root re-starting it as needed during normal operation). Dropping the setuid bit on crontab in favour of a setgid cron alternative also means changing the permissions on the /var/cron/tabs directory which is currently only accessible to root. I'm not sure I would want anybody else to have access there. But it would probably work OK. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Permissions on crontab..
On Wed 2001-01-17 (17:04), Greg Black wrote:
> > In the last episode (Jan 17), Greg Black said:
> > > Michael Bacarella wrote:
> > > > Why is crontab suid root?
> > > >
> > > > I say to myself "To update /var/cron/tabs/ and to signal cron".
> > > >
> > > > Could crontab run suid 'cron'?
> > > >
> > > > If those are the only two things it needs to do, run cron as gid
> > > > 'cron' and make /var/cron/tabs/ group writable by 'cron'.
> > >
> > > It has to run jobs as the correct user and must be able to setuid
> > > accordingly.
> >
> > Not quite. As far as I can tell, crontab is setuid root for the sole
> > purpose of being able to write to /var/cron/tabs. Cron checks the
> > timestamp on the directory every minute, so crontab doesn't have to
> > signal it for changes to get noticed.
>
> > If you're paranoid, you can
> > probably "chgrp cron /var/cron/tabs" and make crontab setgid cron
> > without any ill effects. Cron itself must stay setuid root, of course,
> > so it can run user crontabs as that user.
>
> Dropping the setuid bit on crontab in favour of a setgid cron
> alternative also means changing the permissions on the
> /var/cron/tabs directory which is currently only accessible to
> root. I'm not sure I would want anybody else to have access
> there. But it would probably work OK.
You need only add group read and write permissions for the crontab
group. Since noone is in the crontab group, unless they invoke crontab,
noone will be gaining any "extra" privilege. I also toyed with making
the directory sticky, and adding sanity checks to cron to not invoke
tabs not owned by the user they refer to or root, or at least give
warnings.
FWIW, I had patches to convert 'at' and 'crontab' to being sgid-at
and sgid-crontab ('at' has some really ugly macros that luckily aren't
needed again). I'll probably be doing them again, now that my time is
more sane.
Neil
--
Neil Blakey-Milner
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: Permissions on crontab..
On Wed, Jan 17, 2001 at 12:18:42AM -0500, [EMAIL PROTECTED] wrote: > Why is crontab suid root? > > I say to myself "To update /var/cron/tabs/ and to signal cron". > > Could crontab run suid 'cron'? > > If those are the only two things it needs to do, run cron as > gid 'cron' and make /var/cron/tabs/ group writable by 'cron'. I'm not sure how much this would help. Being able to write arbitary crontabs is eqivelent to root access. Making a user or group who can write cron jobs is almost equivelent to adding a second root user. It would probably be better to spend the time looking at the crontab source code for risky bits of code. (I guess it provides some protection in the case where you are making the crontab user read files it shouldn't. If you can make it write files it shouldn't then you're getting into the root equivelent area). David. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Permissions on crontab..
On Wed, Jan 17, 2001 at 10:28:22AM +, David Malone wrote: > On Wed, Jan 17, 2001 at 12:18:42AM -0500, [EMAIL PROTECTED] wrote: > > > Why is crontab suid root? > > > > I say to myself "To update /var/cron/tabs/ and to signal cron". > > > > Could crontab run suid 'cron'? > > > > If those are the only two things it needs to do, run cron as > > gid 'cron' and make /var/cron/tabs/ group writable by 'cron'. > > I'm not sure how much this would help. Being able to write arbitary > crontabs is eqivelent to root access. Making a user or group who > can write cron jobs is almost equivelent to adding a second root > user. It would probably be better to spend the time looking at the > crontab source code for risky bits of code. > > (I guess it provides some protection in the case where you are > making the crontab user read files it shouldn't. If you can make > it write files it shouldn't then you're getting into the root > equivelent area). Currently crontab only allows you to change others' files if you specify the -u option, which in turn is only allowed if you already are the superuser. ..or did you mean some kind of unintended/faulty behavior? Yes, running crontab setgid does open a window of opportunity for errors, but no more, I think, than running it setuid, as it currently is. G'luck, Peter -- Hey, out there - is it *you* reading me, or is it someone else? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Permissions on crontab..
> ..or did you mean some kind of unintended/faulty behavior? Yes, I ment unintended. > running crontab setgid does open a window of opportunity for errors, > but no more, I think, than running it setuid, as it currently is. True - but I'd say it provides a false sense of security, which might be more damaging than the extra security provided against read-only exploits in crontab. David. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
