| Branch | Commit message | Author | Age |
|---|
| upload | Morphed README -> README.md. | Dale Mellor | 6 months |
| keyring | Dale Mellorʼs key. | Dale Mellor | 6 months |
| trunk | Version to 1.2.0+dmbcs. | Dale Mellor | 4 years |
| |
| Tag | Download | Author | Age |
|---|
| v1.2.3 | mcron-1.2.3.tar.gz mcron-1.2.3.tar.bz2 mcron-1.2.3.zip | atsb | 20 months |
| v1.2.2 | mcron-1.2.2.tar.gz mcron-1.2.2.tar.bz2 mcron-1.2.2.zip | Dale Mellor | 20 months |
| v1.2.1 | mcron-1.2.1.tar.gz mcron-1.2.1.tar.bz2 mcron-1.2.1.zip | atsb | 3 years |
| v1.2.0 | mcron-1.2.0.tar.gz mcron-1.2.0.tar.bz2 mcron-1.2.0.zip | atsb | 4 years |
| v1.1.4 | mcron-1.1.4.tar.gz mcron-1.1.4.tar.bz2 mcron-1.1.4.zip | atsb | 5 years |
| v1.1.3 | mcron-1.1.3.tar.gz mcron-1.1.3.tar.bz2 mcron-1.1.3.zip | Adam Bilbrough | 5 years |
| v1.1.2 | mcron-1.1.2.tar.gz mcron-1.1.2.tar.bz2 mcron-1.1.2.zip | Adam Bilbrough | 6 years |
| v1.1.1 | mcron-1.1.1.tar.gz mcron-1.1.1.tar.bz2 mcron-1.1.1.zip | Mathieu Lirzin | 7 years |
| v1.1 | mcron-1.1.tar.gz mcron-1.1.tar.bz2 mcron-1.1.zip | Mathieu Lirzin | 7 years |
| 1.0.8 | mcron-1.0.8.tar.gz mcron-1.0.8.tar.bz2 mcron-1.0.8.zip | Dale Mellor | 11 years |
| [...] |
| |
| Age | Commit message | Author | Files | Lines |
|---|
| 2023-03-24 | It is 2023.... * src/cron.in
* src/mcron.in
v1.2.3v1.2.2 | Dale Mellor | 2 | -2/+2 |
| 2023-03-24 | Updated use of autoconf guile detection macros....This change also puts back the search specifically for guile version 3.
Note that, if guild is not imminently available (usually part of guile-devel
package) then make will abort with an ugly and very non-descriptive error
message.
* configure.ac
| Dale Mellor | 1 | -4/+4 |
| 2023-03-23 | Version bump to 1.2.2.... * configure.ac: single character edit
| Dale Mellor | 1 | -1/+1 |
| 2023-03-18 | Merge system-wide Vixie cron updates....I don't believe that anyone should be running system-wide cron processes these
days (the attack surface is rather large), but should use separate per-user or
per-service mcron daemon processes. But mcron is advertised as a drop-in
Vixie replacement, so we should do what we can to make it safe in this use
case.
I've performed a basic vetting of the changes against vandalism, but haven't
verified the correctness of the code or done any checking; the changes are
being accepted on the basis that almost anything is an improvement on what
currently exists.
| Dale Mellor | 8 | -159/+338 |
| 2023-03-18 | crontab-access: replace with wrapper, rename to crontab-access-real....The wrapper has two purposes:
1. Not being a script, thereby eliminating the issues with setuid scripts.
2. Purging the environment. crontab-access-real has no need for any
environment variables to do its work, so to prevent tampering with dynamic
linker, libc, or guile, we may as well just unset them all.
This wrapper does introduce a requirement for a C compiler. Ideally it would
be conditional based on whether the wrapper is even going to be built, but
autoconf doesn't like that one bit. Someone with more experience with
autotools should sort that out. In the meantime I guess anyone wanting to
build without a C compiler being present is going to have to edit configure.ac
and re-run bootstrap.
* src/crontab-access.in: renamed to src/crontab-access-real.in
* src/crontab-access.c.in: new file, wrapper for crontab-access-real.
* Makefile.am: inform about crontab-access.c.in and name change to
crontab-access-real. Put crontab-access-real in libexecdir.
| ulfvonbelow | 4 | -3/+34 |
| 2023-03-18 | crontab: split into crontab and setuid helper crontab-access....If a user did somehow manage to install this crontab as functioning
setuid-root in its current state (despite linux ignoring the setuid bit when
executing scripts), it would be a very bad thing for them. It currently has
several glaring security holes. In approximate order from most to least
severe:
1. It blindly calls system() with the user-supplied value of VISUAL or
EDITOR, without dropping privileges. I can't fathom what the author was
thinking, considering (mcron scripts crontab) is littered with comments and
evidence that this is supposed to be a setuid-root program. An attacker
could simply run
EDITOR='sh #' crontab -e
and get a root shell. If you try this, you may find that it coincidentally
doesn't work because bash in particular always drops privileges on startup
if it detects differing real and effective ids. I don't know whether other
shells do this, but it actually doesn't matter as long as you're using
glibc, because its system() consults PATH looking for sh. One false entry
in there and an attacker is running arbitrary code as root. And crontab
doesn't do any sanitizing of *any* environment variables.
2. No attempt is made to sanitize any environment variables. Also, depending
on Guile's startup behavior, trying to sanitize them in guile may be too
late. A wrapper is needed, which would be needed anyway in order to use a
setuid script.
3. No attempt is made to ensure that the temporary file being edited is
newly-created, so an attacker could guess or deduce the filename to be
used, create it in advance, keep it open while crontab opens it, and
overwrite it right before it is copied, allowing them to execute arbitrary
code as any user that dared edit their crontab, including root.
4. Its replace mode accepts a filename. It does no validation whatsoever on
this, opens it, and copies it to the user's crontab as long as it's valid
vixie cron syntax. So for example,
crontab /var/cron/tabs/root && crontab --list
will let you freely read root's (and in a similar manner any other user's)
crontab. Vixie cron includes comments in its valid syntax, so any file that
consists entirely of comments can also be dumped. Also, any file for which
opening it and reading from it has side-effects can have those side-effects
triggered even if it isn't valid vixie cron syntax.
5. Crontabs created in /tmp for editing, as well as crontabs created in
/var/cron/tabs, are world-readable with typical inherited umask.
(1) and (4) are resolved by splitting crontab into two programs: crontab,
which is no longer setuid, and crontab-access, which is. The setuid program no
longer opens any files except for the user's crontab and the allow/deny files,
and it runs no external programs whatsoever. Crontab is run as the invoking
user, so the usual kernel-level permissions checks regarding which files can
be opened for reading apply. The editor is run from crontab, as the invoking
user, so sanitizing of the environment in the setuid helper has no effect on
the editor's environment.
(2) to be resolved shortly with a wrapper program.
(3) is resolved by using mkstemp. The inability to control the mode it is
created with, along with (5), are resolved by setting the umask properly.
* src/mcron/scripts/crontab-access.scm: new module.
* src/mcron/scripts/crontab.scm: move list, delete, and replace
implementation to crontab-access.
* src/crontab-access.in: new file to invoke main of crontab-access.
* Makefile.am: inform of crontab-access.in and crontab-access.scm.
| ulfvonbelow | 4 | -150/+295 |
| 2023-03-18 | config.scm.in: rename to config.scm.in.in, substitute from Makefile....* src/mcron/config.scm.in: renamed to config.scm.in.in.
(config-sbin-dir): new variable.
* Makefile.am: substitute in config.scm.in.
| ulfvonbelow | 3 | -7/+11 |
| 2023-03-18 | Makefile.am: don't install cron as setuid....Setuid scripts are disabled on most systems anyway. Also cron refuses to run
if the real user id isn't 0, so there's no point in it being setuid
anyway. Also also, no attempt at controlling the environment has been made, so
even if the symlink race conditions that make setuid scripts vulnerable were
resolved, it would still be unsafe.
| ulfvonbelow | 1 | -2/+1 |
| 2023-03-18 | cron: use signal numbers instead of symbols....Did this ever work?
* src/mcron/scripts/cron.scm (main): install signal handlers using numbers
that symbols evaluate to instead of symbols.
| ulfvonbelow | 1 | -1/+1 |
| 2023-03-18 | Make vixie cron mode actually work, and work safely...I suspect nobody has used the legacy cron mode in a long time, possibly
ever. If you look at the changes I've made, you'll probably see why I suspect
this. I happen to have tried to use it so that one of my users could use the
format he was familiar with, and ended up making a lot of necessary fixes -
some just to make it work, but many to achieve the most basic of security
requirements.
If anyone has mcron's crontab script installed setuid-root and is on a system
that respects the setuid bit of scripts, or has manually created a setuid
wrapper around the crontab script, they should apply these patches
ASAP.
ulfvonbelow (5):
cron: use signal numbers instead of symbols.
Makefile.am: don't install cron as setuid.
config.scm.in: rename to config.scm.in.in, substitute from Makefile.
crontab: split into crontab and setuid helper crontab-access.
crontab-access: replace with wrapper, rename to crontab-access-real.
Makefile.am | 53 +++-
configure.ac | 10 +-
src/crontab-access-real.in | 45 ++++
src/crontab-access.c.in | 10 +
src/mcron/{config.scm.in => config.scm.in.in} | 1 +
src/mcron/scripts/cron.scm | 2 +-
src/mcron/scripts/crontab-access.scm | 121 +++++++++
src/mcron/scripts/crontab.scm | 255 ++++++++----------
8 files changed, 338 insertions(+), 159 deletions(-)
create mode 100644 src/crontab-access-real.in
create mode 100644 src/crontab-access.c.in
rename src/mcron/{config.scm.in => config.scm.in.in} (97%)
create mode 100644 src/mcron/scripts/crontab-access.scm
--
2.38.1
| ulfvonbelow | 0 | -0/+0 |
| [...] |
| |
| Clone |
|---|
| https://rdmp.org/dmbcs/mcron.git |
