[PATCH] Tighten /etc/crontab permissions - Andrew McNaughton - org.freebsd.freebsd-security

10 messages in org.freebsd.freebsd-security[PATCH] Tighten /etc/crontab permissions

From	Sent On	Attachments
Xin LI	Aug 10, 2004 9:43 am
Doug Barton	Aug 10, 2004 10:03 am
Xin LI	Aug 10, 2004 11:17 am
Garance A Drosihn	Aug 10, 2004 12:13 pm
Gustavo A. Baratto	Aug 10, 2004 12:52 pm
Jason Stone	Aug 10, 2004 1:29 pm
Andrew McNaughton	Aug 10, 2004 1:38 pm
Ryan Thompson	Aug 11, 2004 1:56 pm
Xin LI	Aug 11, 2004 9:05 pm
Doug Barton	Aug 11, 2004 9:56 pm

Subject:	[PATCH] Tighten /etc/crontab permissions
From:	Andrew McNaughton (and...@scoop.co.nz)
Date:	Aug 10, 2004 1:38:04 pm
List:	org.freebsd.freebsd-security

Hiding the contents of /etc/crontab sounds to me like security through obscurity. There's very little depth to it, and it's more likely to give a false sense of security than anything real.

Anyone hardcoding a mysql password in the command line is asking for trouble, regardless of whether /etc/crontab is readable. Once running, It's visible to anyone via tools like ps and procfs.

Better to leave the neophyte administrator to figure out how not to put the password or anything else sensitive on the command line, rather than letting them believe that it's secure because the crontab file is not readable.

On Tue, 10 Aug 2004, Gustavo A. Baratto wrote:

It is better to have something secure by default. If someone wants to open up the crontab in /etc/crontab for other users to see it, he/she can do it on his/her own risk. Many ppl that are not very familiar with system administration nor security, but yet manage a server could add cronjobs that could be very harmful to themselves and they don't know (eg. mysqldump for backups with the password hardcoded in the command).

Maybe, the purpose of /etc/crontab is exactly to be a read-by-all file. That's fine, but in this case, a security warning with BIG letters should be printed in the very beginning of the file.

my $0.02 ;)

----- Original Message ----- From: "Garance A Drosihn" <dro...@rpi.edu> To: "Xin LI" <delp...@frontfree.net>; "Doug Barton" <Dou...@freebsd.org> Cc: <free...@freebsd.org> Sent: Tuesday, August 10, 2004 12:01 PM Subject: Re: [PATCH] Tighten /etc/crontab permissions

At 2:10 AM +0800 8/11/04, Xin LI wrote:

On Tue, Aug 10, 2004 at 10:02:09AM -0700, Doug Barton wrote:

Can you elaborate on your thinking?

I'm not sure if this is a sort of abusing systemwide crontabs, but the administrators at my company have used them to run some tasks periodicly under other identities (to limit these tasks' privilege), and it provided a somewhat "centralized" management so they would prefer to use systemwide crontab rather than per-user ones.

You could get about the same effect by having them all under root's crontab, and then having the entry 'su' to the appropriate userid before running. So it is centralized in one crontab (root's), but it is protected from prying eyes.

What do you think about the benefit for users being able to see the system crontab? I think knowing what would be executed under others' identity is (at least) not always a good thing, especially the users we generally don't fully trust...

For generic system tasks, it can be useful to know when they run. Maybe this means more to me because I'm actually awake at all odd hours of the morning, so I notice the effects of some of those runs. My runs of 'cvsup_mirror', for instance.

Basically, I use the system crontab for events where I think it is safe for every user to know when the events occur, and use other crontabs for the things I want to keep private. Just a personal preference thing, obviously.

No added Sugar. Not tested on animals. May contain traces of Nuts. If irritation occurs, discontinue use.

------------------------------------------------------------------- Andrew McNaughton Living in a shack in Tasmania and...@scoop.co.nz Between the bush and the sea

Mobile: +61 422 753 792 http://staff.scoop.co.nz/andrew/cv.doc http://www.scoop.co.nz/

	Start a set with this search
	Include this search in one of my sets
	Exclude this search from one of my sets