[redhat-lspp] [RFC] [PATCH] extending cron subsys
JANAK DESAI
janak at us.ibm.com
Tue Dec 20 19:11:46 UTC 2005
Stephen Smalley wrote:
>On Tue, 2005-11-08 at 12:06 -0500, Janak Desai wrote:
>
>
>>These patches (fc4 and fc5 versions) extend the cron subsystem
>>to allow a user to submit cron jobs from different security contexts,
>>and have the cron daemon execute them in the context from which they
>>were submitted.
>>
>>
>
>Hi,
>
>Not sure if you've made further changes to these patches, but FWIW...
>
>
Thanks Stephen. No, I have not made any changes to these. I will
update them appropriately and send them out in about two weeks (once I am
back to work)
>
>
>>Currently, a user's crontab file is stored in the /var/spool/cron
>>directory as the user's name. With this patch a user can execute
>>crontab with a new option '-c' to append the current security
>>context to the crontab file name. The cron daemon, as part of
>>processing cron jobs, will attempt to set the security context
>>of the job to the context appended to the user name (if -c was
>>used with crontab). If the crontab file does not contain a
>>security context in its name (crontab without -c), the cron daemon
>>will continue to operate as it does now (use get_default_context_*
>>to obtain cron job's security context) for that perticular job.
>>
>>
>
>So to be clear: we are still using the existing SELinux entrypoint
>permission check by crond to ensure that commands are not run from a
>maliciously fabricated crontab file (which may now also include a
>fabricated context in as its name suffix) in a privileged context,
>right?
>
>
>
Yes, that's correct. I did not want to take away that security feature
of cron
on selinux.
>>Similarly, admins can append security contexts to files in
>>{hourly,daily,monthly} directories if they would like those jobs
>>to execute with a certain security contexts.
>>
>>
>Is that really true? It seems like your patch is based on crontab file
>name, which would be /etc/crontab in the system case, not the
>individual /etc/cron.{hourly,daily,monthly}/* scripts that are run as
>jobs by that crontab file.
>
>
Ah, I see that now. I will investigate this further and make appropriate
modifications so admins do have flexibility of running certain jobs with
a specified context.
>
>
>>So far, I haven't made any changes to cron "allow/deny" logic.
>>Which means an admin will have to explicity provide security
>>context in addition to user name to allow/deny cron capability.
>>Does it make more sense to keep allow/deny logic granular to just
>>a user or to a user+context? That is, if users are allowed/denied
>>to submit cron jobs, they can/can't do that from any contexts
>>to which they have access.
>>
>>
>
>Not certain myself, but you could provide both capabilities as config
>options.
>
>
Ok. Will look into providing a config option.
>
>
>>I haven't made changes to man pages, but will do so once I get
>>feedback on the patch itself.
>>
>>
>
>A few comments below. However, I strongly recommend that you get this
>patch reviewed by actual cron maintainers. We received a lot of good
>feedback on the original vixie cron SELinux patch from the Debian cron
>maintainer that led to a number of changes in it, IIRC.
>
>
>
Ok, thanks. I will make the suggested fixes and will definitely send the
updated patches to cron maintainers.
><snip>
>diff -Naurp vixie-cron-4.1/crontab.c mult/crontab.c
>--- vixie-cron-4.1/crontab.c 2005-11-08 15:58:56.000000000 +0000
>+++ mult/crontab.c 2005-11-07 22:31:35.000000000 +0000,
>@@ -157,6 +184,29 @@ parse_args(int argc, char *argv[]) {
> usage("bad debug option");
> break;
> #endif
>+#ifdef WITH_SELINUX
>+ case 'c':
>+ if (is_selinux_enabled() > 0) {
>+ if (getcon(&context)) {
>+ fprintf(stderr,
>+ "Cannot obtain process context\n");
>+ exit(ERROR_EXIT);
>+ }
>
>This needs to be getprevcon(), not getcon(), IIUC. Under strict policy,
>crontab runs in its own domain separate from the user's domain, whereas
>you want to capture the caller's security context (not crontab's own
>security context).
>
>diff -Naurp vixie-cron-4.1/database.c mult/database.c
>--- vixie-cron-4.1/database.c 2005-11-08 15:58:57.000000000 +0000
>+++ mult/database.c 2005-11-07 22:53:40.000000000 +0000
>@@ -246,46 +262,46 @@ process_crontab(const char *uname, const
> } else if ((pw = getpwnam(uname)) == NULL) {
> /* file doesn't have a user in passwd file.
> */
>- log_it(fname, getpid(), "ORPHAN", "no passwd entry");
>+ log_it(uname, getpid(), "ORPHAN", "no passwd entry");
> goto next_crontab;
> }
>
>Why not leave the log_it() calls alone and thus get the full context
>information included in the log entries?
>
>diff -Naurp vixie-cron-4.1/user.c mult/user.c
>--- vixie-cron-4.1/user.c 2005-11-08 15:58:57.000000000 +0000
>+++ mult/user.c 2005-11-08 14:48:46.000000000 +0000
>@@ -47,8 +47,14 @@ static int get_security_context(const ch
> char *seuser=NULL;
> char *level=NULL;
> *rcontext = NULL;
>+ char *tptr;
>
>- if (getseuserbyname(name, &seuser, &level) == 0) {
>+ tptr = strchr(tabname, ':');
>+ if (tptr) {
>+ tptr++;
>+ scontext = (security_context_t) strdup(tptr);
>
>strdup can fail.
>
>
>
More information about the redhat-lspp
mailing list