On Thu, 24 Jan 2008, Daniel Hagerty wrote:
Scott Ehrlich <[EMAIL PROTECTED]> writes:
Considering the balance of changing crontab's source code vs noexec,
noexec seems the more reasonable approach of the two. Not the best
solution, but weighing the two options, possibly the most practical at
this point.
Except I've reached the point where I have little faith it will
help with your unspecified problem.
noexec will hose you if an otherwise legitimate job is on that
filesystem, because it won't exec. On the flip side, noexec does
nothing to prevent a priviledge escalation problem if a user puts
". /foo/bar/script.sh" as a command for cron (oh look, another way
where user A doing something foolish can lead to user B impersonating
him, and therefore forget what I said about fixing exec*() probably
being enough).
Is it possible to permanently change /tmp and /var/tmp to chmod o-wx, and
then prevent anything from ever creating world writable and executable in
those folders?
Then, is it possible to carry those changes to individual user home
directories?
I could do the chmod myself then modify the permissions of chmod to 700.
But that doesn't answer how applications will behave if they need to
create directories... would umask help?
Are we getting the idea yet? This all would just be so much more
productive if you'd just tell us what thought it was that precipitated
"how do I limit cron's capabilities?".
I just can't help but get the feeling that our partial picture
will lead you to doing something that produces an undeserved sense of
security.
It's just one of those things where I'm simply following directions.
Thanks.
Scott
_______________________________________________
bblisa mailing list
[email protected]
http://www.bblisa.org/mailman/listinfo/bblisa
