Package: cron
Version: 3.0pl1-132
Severity: important
Tags: patch
Mar 16 20:36:39 xev cron[14032]: (rjc) ENTRYPOINT FAILED (crontabs/rjc)
Mar 16 20:36:39 xev cron[14032]: (torrent) ENTRYPOINT FAILED (crontabs/torrent)
Mar 16 20:36:39 xev cron[14032]: (test) ENTRYPOINT FAILED (crontabs/test)
When I restart crond (or run crontab for a user) on a system with the "strict"
configuration of SE Linux policy (user roles other than unconfined_r) I see
the above in the cron log.
In file included from user.c:34:
/usr/include/selinux/flask.h:5:2: warning: #warning "Please remove any
#include's of this header in your source code." [-Wcpp]
#warning "Please remove any #include's of this header in your source code."
^~~~~~~
/usr/include/selinux/flask.h:6:2: warning: #warning "Instead, use
string_to_security_class() to map the class name to a value." [-Wcpp]
#warning "Instead, use string_to_security_class() to map the class name to a
value."
^~~~~~~
In file included from user.c:35:
/usr/include/selinux/av_permissions.h:1:2: warning: #warning "Please remove any
#include of this header in your source code." [-Wcpp]
#warning "Please remove any #include of this header in your source code."
^~~~~~~
/usr/include/selinux/av_permissions.h:2:2: warning: #warning "Instead, use
string_to_av_perm() to map the permission name to a value." [-Wcpp]
#warning "Instead, use string_to_av_perm() to map the permission name to a
value."
^~~~~~~
When I compile the cron package I see the above. The above is the cause of
the incorrect processing of entry points.
The following patch fixes these problems.
Please note that the bug means that when the cron package that is currently in
testing is run with the SE Linux libraries in testing it checks for
execute_no_trans permission not entrypoint. It is unlikely that a hostile
party could create a crontab file with a context for which execute_no_trans is
allowed without having the ability to get elevated privileges in other ways,
but it can't be theoretically impossible.
I can't be certain that there are no security implications of the bug so I
think that getting this fix into Buster is important.
diff -ru cronold/cron-3.0pl1/user.c cronnew/cron-3.0pl1/user.c
--- cronold/cron-3.0pl1/user.c 2019-03-16 20:47:36.000000000 +1100
+++ cronnew/cron-3.0pl1/user.c 2019-03-16 20:47:19.407332577 +1100
@@ -31,8 +31,6 @@
#ifdef WITH_SELINUX
#include <selinux/context.h>
#include <selinux/selinux.h>
-#include <selinux/flask.h>
-#include <selinux/av_permissions.h>
#include <selinux/get_context_list.h>
static int get_security_context(char *name, int crontab_fd, security_context_t
@@ -110,14 +108,26 @@
* permission check for this purpose.
*/
+ security_class_t tclass = string_to_security_class("file");
+ if (!tclass) {
+ log_it(name, getpid(), "Failed to translate security class file",
tabname);
+ return 0;
+ }
+
+ access_vector_t bit = string_to_av_perm(tclass, "entrypoint");
+ if (!bit) {
+ log_it(name, getpid(), "Failed to translate av perm entrypoint",
tabname);
+ return 0;
+ }
+
for(i = 0; i < list_count; i++)
{
retval = security_compute_av(context_list[i],
file_context,
- SECCLASS_FILE,
- FILE__ENTRYPOINT,
+ tclass,
+ bit,
&avd);
- if(!retval && ((FILE__ENTRYPOINT & avd.allowed) == FILE__ENTRYPOINT)) {
+ if(!retval && ((bit & avd.allowed) == bit)) {
*rcontext = strdup(context_list[i]);
freecon(file_context);
freeconary(context_list);
