Re: setgid crontab

[Matt Zimmerman]

On Mon, Sep 01, 2003 at 07:32:45PM -0500, Steve Greenland wrote:

> On 17-Aug-03, 17:11 (CDT), Steve Greenland <[EMAIL PROTECTED]> wrote: 
> > I'd hoped to get the suggestions here and Solar Designer's work
> > incorporated tested, and uploaded before I left on a 2 week vacation,
> > but I'm not going to get it done. But it *is* in progess, will be my
> > priority after I return at the end of August.
> 
> Just uploaded to ftp-master.debian.org.
> 
> "It works for me."

Snatched from queue/accepted; so far everything works as expected.

-- 
 - mdz

Re: setgid crontab

[Steve Greenland]

On 17-Aug-03, 17:11 (CDT), Steve Greenland <[EMAIL PROTECTED]> wrote: 
> I'd hoped to get the suggestions here and Solar Designer's work
> incorporated tested, and uploaded before I left on a 2 week vacation,
> but I'm not going to get it done. But it *is* in progess, will be my
> priority after I return at the end of August.

Just uploaded to ftp-master.debian.org.

"It works for me."

Russell, I'm sending you the diff seperately.

Steve

-- 
Steve Greenland
The irony is that Bill Gates claims to be making a stable operating
system and Linus Torvalds claims to be trying to take over the
world.   -- seen on the net

Re: setgid crontab

[Matt Zimmerman]

On Mon, Aug 04, 2003 at 07:55:34PM -0700, Blars Blarson wrote:

> In article <[EMAIL PROTECTED]> [EMAIL PROTECTED] writes:
> >On Sat, Aug 02, 2003 at 02:51:03PM -0500, Steve Greenland wrote:
> >Under this setup, when cron opens a crontab file, it should fstat() it and
> >check that it is owned by the uid under which its contents will be executed
> >before trusting it.
> 
> It should not trust symbolic links either.  Otherwise it instanly promotes
> everything that looks like a crontab into one.

The attack scenarios for this one are pretty unlikely, but a little paranoia
can't hurt here.  I agree:

http://lists.debian.org/debian-devel/2003/debian-devel-200308/msg00191.html

-- 
 - mdz

Re: setgid crontab

[Blars Blarson]

In article <[EMAIL PROTECTED]> [EMAIL PROTECTED] writes:
>On Sat, Aug 02, 2003 at 02:51:03PM -0500, Steve Greenland wrote:
>Under this setup, when cron opens a crontab file, it should fstat() it and
>check that it is owned by the uid under which its contents will be executed
>before trusting it.

It should not trust symbolic links either.  Otherwise it instanly promotes
everything that looks like a crontab into one.


-- 
Blars Blarson   [EMAIL PROTECTED]
http://www.blars.org/blars.html
"Text is a way we cheat time." -- Patrick Nielsen Hayden

Re: setgid crontab

[Bernd Eckenfels]

On Mon, Aug 04, 2003 at 08:10:47AM +0200, Tollef Fog Heen wrote:
> Which is why you mount NFS shares with the intr flag set so that you
> can at least kill it and restart it.

Which is broken on most Linux Kernels. So is soft.

Greetings
Bernd
-- 
  (OO)  -- [EMAIL PROTECTED] --
 ( .. )  [EMAIL PROTECTED],linux.de,debian.org} http://home.pages.de/~eckes/
  o--o *plush*  2048/93600EFD  [EMAIL PROTECTED]  +497257930613  BE5-RIPE
(OO)  When cryptography is outlawed, bayl bhgynjf jvyy unir cevinpl!

Re: setgid crontab

[Russell Coker]

On Mon, 4 Aug 2003 16:10, Tollef Fog Heen wrote:
> | Also you don't want the main copy of cron to search auto-mounted user
> | home directories.  If you do that then a failure of the NFS server will
> | put cron in "D" state...
>
> Which is why you mount NFS shares with the intr flag set so that you
> can at least kill it and restart it.

Of course it's nice to have cron jobs to monitor the access of NFS shared and 
kill/restart daemons...

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page

Re: setgid crontab

[Tollef Fog Heen]

* Russell Coker 

| Also you don't want the main copy of cron to search auto-mounted user home 
| directories.  If you do that then a failure of the NFS server will put cron 
| in "D" state...

Which is why you mount NFS shares with the intr flag set so that you
can at least kill it and restart it.

-- 
Tollef Fog Heen,''`.
UNIX is user friendly, it's just picky about who its friends are  : :' :
  `. `' 
`-  

Re: setgid crontab

[Russell Coker]

On Mon, 4 Aug 2003 08:25, Steve Greenland wrote:
> On 03-Aug-03, 11:37 (CDT), Joey Hess <[EMAIL PROTECTED]> wrote:
> > (As a user, what I really want is a .crontab file in my home directory,
> > so I can put it under revision control.)
>
> One potential problem (or issue) I see with this is automounted home
> directories. A file that was there while the user was logged in and then
> disappeared might not have the effect you want. Or it might - I can see
> arguments both ways.

Also you don't want the main copy of cron to search auto-mounted user home 
directories.  If you do that then a failure of the NFS server will put cron 
in "D" state...

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page

Re: setgid crontab

[Steve Greenland]

On 03-Aug-03, 11:37 (CDT), Joey Hess <[EMAIL PROTECTED]> wrote: 
> (As a user, what I really want is a .crontab file in my home directory,
> so I can put it under revision control.)

One potential problem (or issue) I see with this is automounted home
directories. A file that was there while the user was logged in and then
disappeared might not have the effect you want. Or it might - I can see
arguments both ways.

The fact that the installed copy isn't local doesn't prevent you from
using version control, although it does require more discipline. Or a
wrapper around crontab, or a wicked definition for "EDITOR".

Steve

-- 
Steve Greenland
The irony is that Bill Gates claims to be making a stable operating
system and Linus Torvalds claims to be trying to take over the
world.   -- seen on the net

Re: setgid crontab

[Steve Greenland]

On 03-Aug-03, 11:37 (CDT), Joey Hess <[EMAIL PROTECTED]> wrote: 
> 
> One possible gotcha is that if crontab(1) does any sanity checks of the
> crontab files, cron could expect them to be pre-sanitised, and might
> behave badly if an unsanitised file is put into place by a user.

Crontab and cron check the file with the same functions. It will fail to
load once, and since cron only reads files that have been updated, it
won't endlessly try to reload it once a minute.

Steve

-- 
Steve Greenland
The irony is that Bill Gates claims to be making a stable operating
system and Linus Torvalds claims to be trying to take over the
world.   -- seen on the net

Re: setgid crontab

[Tollef Fog Heen]

* Joey Hess 

| (As a user, what I really want is a .crontab file in my home directory,
| so I can put it under revision control.)

have a .crontab in your ~ with a line similar to

@daily crontab $HOME/.crontab

?

(Naturally, you'd have to get that crontab initially installed,
though.)

-- 
Tollef Fog Heen,''`.
UNIX is user friendly, it's just picky about who its friends are  : :' :
  `. `' 
`-  

Re: setgid crontab

[Manoj Srivastava]

On Sun, 3 Aug 2003 12:37:46 -0400, Joey Hess <[EMAIL PROTECTED]> said: 

> (As a user, what I really want is a .crontab file in my home
> directory, so I can put it under revision control.)

Umm, as a work around, I have ~/etc/crontab, and at one time
 had a cron job that tested the output of crontab -l periodically, and
 updated as needed. (I update my cron file seldom enough that I now
 just do it manually). 

manoj
-- 
Recent research has tended to show that the Abominable No-Man is being
replaced by the Prohibitive Procrastinator. C.N. Parkinson
Manoj Srivastava   <[EMAIL PROTECTED]>  
1024R/C7261095 print CB D9 F4 12 68 07 E4 05  CC 2D 27 12 1D F5 E8 6E
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C

Re: setgid crontab

[Joey Hess]

Steve Greenland wrote:
> Apropos of the recent setuid/setgid thread, and also being prodded by
> Stephen Frost, I've changed crontab to be setgid 'cron' rather than
> setuid 'root'. Beyond the coding (which is mostly removing setuid()
> calls), this involves the following changes:
> 
> add system group 'cron'
> 
> change /var/spool/cron/crontabs from 755 root.root to 775 root.cron
> 
> change crontab files in the spool directory from 600 root.root to 600
> userid.cron
> 
> At first glance, the only access I've added with this is that a user can
> now view or edit (but not delete) her crontab file directly in the spool
> directory. Since one could all that with the crontab command anyway, it
> doesn't seem a big deal.
> 
> Comments, suggestions?

One possible gotcha is that if crontab(1) does any sanity checks of the
crontab files, cron could expect them to be pre-sanitised, and might
behave badly if an unsanitised file is put into place by a user.

(As a user, what I really want is a .crontab file in my home directory,
so I can put it under revision control.)

-- 
see shy jo


pgpYBd5QDWDKw.pgp
Description: PGP signature

Re: setgid crontab

[Steve Greenland]

On 02-Aug-03, 23:36 (CDT), Matt Zimmerman <[EMAIL PROTECTED]> wrote: 
> So: open, fstat, stat, compare fstat.st_ino to stat.st_ino, check
> fstat.st_uid.  O_EXCL should also be used when writing to the directory.

That introduces a (possibly minor) race condition: if the user runs
crontab to replace their file between the open() and stat() calls,
this check will fail. Not a huge problem, because it will pick it up
correctly the next time cron runs. And better to have the check than
not, I agree.

For the record, the way crontab add/replaces the user's file is to
first create a tmp file in the spool directory, check that it parses
correctly, and then rename() it to the user's name.

I'll take a look at the OpenBSD and Solar Designer implementations, and
see what they did.

> It should be noted somewhere that these protections do little good if the
> system allows users to give away their files (as with the recent XFS bug),
> and gid cron becomes equivalent to root again.

Nor do they do any good if root's password is empty. Not cron's problem.
(Insert standard homily about security and the chain's weakest link.)

Steve

-- 
Steve Greenland
The irony is that Bill Gates claims to be making a stable operating
system and Linus Torvalds claims to be trying to take over the
world.   -- seen on the net

Re: setgid crontab

[Matt Zimmerman]

On Sun, Aug 03, 2003 at 12:17:27AM -0400, Daniel Jacobowitz wrote:

> On Sat, Aug 02, 2003 at 09:19:23PM -0400, Matt Zimmerman wrote:
> > Under this setup, when cron opens a crontab file, it should fstat() it
> > and check that it is owned by the uid under which its contents will be
> > executed before trusting it.
> 
> It is also important to stat beforehand, to prevent stupid symlink tricks,
> if we're going to be paranoid about writes to the directory.  Then you
> compare dev/inode with the fstat.

That couldn't hurt either.  Though, I think it is more correct to stat after
opening the file, so that we do not rely on the filesystem's allocation of
inode numbers (the inode number of the open file cannot be reused).

So: open, fstat, stat, compare fstat.st_ino to stat.st_ino, check
fstat.st_uid.  O_EXCL should also be used when writing to the directory.

It should be noted somewhere that these protections do little good if the
system allows users to give away their files (as with the recent XFS bug),
and gid cron becomes equivalent to root again.

-- 
 - mdz

Re: setgid crontab

[Daniel Jacobowitz]

On Sat, Aug 02, 2003 at 09:19:23PM -0400, Matt Zimmerman wrote:
> On Sat, Aug 02, 2003 at 02:51:03PM -0500, Steve Greenland wrote:
> 
> > Apropos of the recent setuid/setgid thread, and also being prodded by
> > Stephen Frost, I've changed crontab to be setgid 'cron' rather than
> > setuid 'root'. Beyond the coding (which is mostly removing setuid()
> > calls), this involves the following changes:
> > 
> > add system group 'cron'
> > 
> > change /var/spool/cron/crontabs from 755 root.root to 775 root.cron
> > 
> > change crontab files in the spool directory from 600 root.root to 600
> > userid.cron
> > 
> > At first glance, the only access I've added with this is that a user can
> > now view or edit (but not delete) her crontab file directly in the spool
> > directory. Since one could all that with the crontab command anyway, it
> > doesn't seem a big deal.
> > 
> > Comments, suggestions?
> 
> If you were here, I would hug you, and if we ever do meet in person, I owe
> you a beer.
> 
> I think a few more changes are necessary, though.  With the crontabs
> directory mode 775, a user who gains access to the 'cron' group could create
> a crontab file for root and thereby gain root privileges easily.
> 
> Under this setup, when cron opens a crontab file, it should fstat() it and
> check that it is owned by the uid under which its contents will be executed
> before trusting it.

It is also important to stat beforehand, to prevent stupid symlink
tricks, if we're going to be paranoid about writes to the directory.
Then you compare dev/inode with the fstat.


-- 
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer

Re: setgid crontab

[Matt Zimmerman]

On Sat, Aug 02, 2003 at 11:25:47PM +0200, Bernd Eckenfels wrote:

> On Sat, Aug 02, 2003 at 03:53:00PM -0500, Steve Greenland wrote:
> > To ship the setgid program, I need to have the group 'cron' on the
> > build system.
> 
> i think this is covered by fakeroot.

It is not, though doogie and asuffield seem to have taken an interest in
implementing it.

-- 
 - mdz

Re: setgid crontab

[Matt Zimmerman]

On Sat, Aug 02, 2003 at 02:51:03PM -0500, Steve Greenland wrote:

> Apropos of the recent setuid/setgid thread, and also being prodded by
> Stephen Frost, I've changed crontab to be setgid 'cron' rather than
> setuid 'root'. Beyond the coding (which is mostly removing setuid()
> calls), this involves the following changes:
> 
> add system group 'cron'
> 
> change /var/spool/cron/crontabs from 755 root.root to 775 root.cron
> 
> change crontab files in the spool directory from 600 root.root to 600
> userid.cron
> 
> At first glance, the only access I've added with this is that a user can
> now view or edit (but not delete) her crontab file directly in the spool
> directory. Since one could all that with the crontab command anyway, it
> doesn't seem a big deal.
> 
> Comments, suggestions?

If you were here, I would hug you, and if we ever do meet in person, I owe
you a beer.

I think a few more changes are necessary, though.  With the crontabs
directory mode 775, a user who gains access to the 'cron' group could create
a crontab file for root and thereby gain root privileges easily.

Under this setup, when cron opens a crontab file, it should fstat() it and
check that it is owned by the uid under which its contents will be executed
before trusting it.

I can't think of any problems with the user being able to read their own
crontab file, but there could be unexpected consequences in allowing them to
write to it without going through crontab.  It should be verified that cron
is performing the same validation checks on the contents that would be done
by crontab before accepting the new crontab file.

I will think about this some more.  Interestingly enough, a quick search
reveals that OpenBSD and SCO use a setgid cron setup, rather than setuid
root.  It may be worthwhile to check out OpenBSD's source code and see what
changes were made to support this configuration.

-- 
 - mdz

Re: setgid crontab

[Russell Coker]

On Sun, 3 Aug 2003 09:03, Steve Greenland wrote:
> > It's easy enough to make the directory containing the files be mode 0775
> > to solve this.
>
> I'll assume you meant 0770? 775 and 771 don't solve the problem, and I
> don't see the point of 774 over 770...

Yes, I meant to say 0770.

> > I don't know why the directory is currently mode 0755,
>
> It's the debian default, and I never considered the issue before, and
> nobody complained. But it's easy to fix at this point.

Great!  Please email me the .diff.gz as soon as you get this done so I can 
produce a package for SE Linux.

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page

Re: setgid crontab

[Matt Zimmerman]

On Sat, Aug 02, 2003 at 03:53:00PM -0500, Steve Greenland wrote:

> On 02-Aug-03, 14:51 (CDT), Steve Greenland <[EMAIL PROTECTED]> wrote: 
> > Beyond the coding (which is mostly removing setuid()
> > calls), this involves the following changes:
> 
> To ship the setgid program, I need to have the group 'cron' on the
> build system. Not a problem for me, of course, but how do I indicate
> to the build daemons this requirement? Or should I just set the group
> and mode of /usr/bin/crontab and the directories in the postinst? The
> downside is that doing so would seem to override any local requirements
> or dpkg-statoverrides that the admin might have set.
> 
> I did not find any guidance in either the Policy manual or the
> Developers Reference, if I missed it, please point me in the right
> direction.

This is a common problem, and there have been discussions recently about how
to address it.  The solutions which I find most appealing involve creating
some simple tools to set ownership to non-existent users in the .deb, and
running adduser/addgroup in the preinst.

However, until that solution is implemented, the next best thing is usually
to do something like:

if ! dpkg-statoverride --list $file >/dev/null; then
  ...do the magic...
fi

This way, if the admin adds a statoverride, you leave things alone.

-- 
 - mdz

Re: setgid crontab

[Steve Greenland]

On 02-Aug-03, 17:00 (CDT), Russell Coker <[EMAIL PROTECTED]> wrote: 
> On Sun, 3 Aug 2003 05:51, Steve Greenland wrote:
> Sounds good to me.  You are not the first person to do it however, I believe 
> that Solar Designer did the same thing for OpenWall (of course when Solar 
> Designer has the same security idea as you then it's a good sign you're doing 
> the right thing).

I'd be flattered, except it wasn't my idea, I just finally got around to
doing it. :-) But I'll take a look at SD's version.

> If a user is listed in /etc/cron.deny then "crontab -l" does not work for 
> them, so if you permit them to cat the file directly then you are changing 
> the functionality, which may not be desired.

Ah, good catch. Of course, neither does 'crontab -e', but I suppose root
could have put the file their for them.

> It's easy enough to make the directory containing the files be mode 0775 to 
> solve this.

I'll assume you meant 0770? 775 and 771 don't solve the problem, and I
don't see the point of 774 over 770...

> I don't know why the directory is currently mode 0755,

It's the debian default, and I never considered the issue before, and
nobody complained. But it's easy to fix at this point.

Steve

-- 
Steve Greenland
The irony is that Bill Gates claims to be making a stable operating
system and Linus Torvalds claims to be trying to take over the
world.   -- seen on the net

Re: setgid crontab

[Steve Greenland]

On 02-Aug-03, 16:25 (CDT), Bernd Eckenfels <[EMAIL PROTECTED]> wrote: 
> On Sat, Aug 02, 2003 at 03:53:00PM -0500, Steve Greenland wrote:
> > To ship the setgid program, I need to have the group 'cron' on the
> > build system.
> 
> i think this is covered by fakeroot.

No, 'chgrp cron foo' fails if group cron doesn't exist, because it can't
convert the name to a gid.

Steve

-- 
Steve Greenland
The irony is that Bill Gates claims to be making a stable operating
system and Linus Torvalds claims to be trying to take over the
world.   -- seen on the net

Re: setgid crontab

[Russell Coker]

On Sun, 3 Aug 2003 05:51, Steve Greenland wrote:
> Apropos of the recent setuid/setgid thread, and also being prodded by
> Stephen Frost, I've changed crontab to be setgid 'cron' rather than
> setuid 'root'. Beyond the coding (which is mostly removing setuid()
> calls), this involves the following changes:

Sounds good to me.  You are not the first person to do it however, I believe 
that Solar Designer did the same thing for OpenWall (of course when Solar 
Designer has the same security idea as you then it's a good sign you're doing 
the right thing).

If we are going to remove SETUID/SETGID programs then we should look at what 
Solar Designer is doing, particularly in TCB http://www.openwall.com/tcb/ .

> At first glance, the only access I've added with this is that a user can
> now view or edit (but not delete) her crontab file directly in the spool
> directory. Since one could all that with the crontab command anyway, it
> doesn't seem a big deal.

If a user is listed in /etc/cron.deny then "crontab -l" does not work for 
them, so if you permit them to cat the file directly then you are changing 
the functionality, which may not be desired.

It's easy enough to make the directory containing the files be mode 0775 to 
solve this.  I don't know why the directory is currently mode 0755, this 
allows any user to see who has a crontab file, when it was last updated, and 
how big it is.  I don't think that this is desirable (my SE Linux policy 
prevents such access).

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page

Re: setgid crontab

[Bernd Eckenfels]

On Sat, Aug 02, 2003 at 03:53:00PM -0500, Steve Greenland wrote:
> To ship the setgid program, I need to have the group 'cron' on the
> build system.

i think this is covered by fakeroot.

Greetings
Bernd
-- 
  (OO)  -- [EMAIL PROTECTED] --
 ( .. )  [EMAIL PROTECTED],linux.de,debian.org} http://home.pages.de/~eckes/
  o--o *plush*  2048/93600EFD  [EMAIL PROTECTED]  +497257930613  BE5-RIPE
(OO)  When cryptography is outlawed, bayl bhgynjf jvyy unir cevinpl!

Re: setgid crontab

[Steve Greenland]

On 02-Aug-03, 14:51 (CDT), Steve Greenland <[EMAIL PROTECTED]> wrote: 
> Beyond the coding (which is mostly removing setuid()
> calls), this involves the following changes:

To ship the setgid program, I need to have the group 'cron' on the
build system. Not a problem for me, of course, but how do I indicate
to the build daemons this requirement? Or should I just set the group
and mode of /usr/bin/crontab and the directories in the postinst? The
downside is that doing so would seem to override any local requirements
or dpkg-statoverrides that the admin might have set.

I did not find any guidance in either the Policy manual or the
Developers Reference, if I missed it, please point me in the right
direction.

Thanks,
Steve

-- 
Steve Greenland
The irony is that Bill Gates claims to be making a stable operating
system and Linus Torvalds claims to be trying to take over the
world.   -- seen on the net

Re: setgid crontab

[Bernd Eckenfels]

On Sat, Aug 02, 2003 at 02:51:03PM -0500, Steve Greenland wrote:
> change /var/spool/cron/crontabs from 755 root.root to 775 root.cron
> change crontab files in the spool directory from 600 root.root to 600
> userid.cron

It would ne nice, if cron is checking file owner then. So that the file
"user1" is owned by "user1" (or root) any nobody else.

Greetings
Bernd
-- 
  (OO)  -- [EMAIL PROTECTED] --
 ( .. )  [EMAIL PROTECTED],linux.de,debian.org} http://home.pages.de/~eckes/
  o--o *plush*  2048/93600EFD  [EMAIL PROTECTED]  +497257930613  BE5-RIPE
(OO)  When cryptography is outlawed, bayl bhgynjf jvyy unir cevinpl!

setgid crontab

[Steve Greenland]

Apropos of the recent setuid/setgid thread, and also being prodded by
Stephen Frost, I've changed crontab to be setgid 'cron' rather than
setuid 'root'. Beyond the coding (which is mostly removing setuid()
calls), this involves the following changes:

add system group 'cron'

change /var/spool/cron/crontabs from 755 root.root to 775 root.cron

change crontab files in the spool directory from 600 root.root to 600
userid.cron

At first glance, the only access I've added with this is that a user can
now view or edit (but not delete) her crontab file directly in the spool
directory. Since one could all that with the crontab command anyway, it
doesn't seem a big deal.

Comments, suggestions?


-- 
Steve Greenland
The irony is that Bill Gates claims to be making a stable operating
system and Linus Torvalds claims to be trying to take over the
world.   -- seen on the net