Hello,
> > 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. Please find here an other patch based on Russell's one.The changes compared to the original patch are the fact that I'm cleaning context_list in case of error and I'm also using security_deny_unknown() to check whether we should allow the access in case the class or the permission is not defined.
Russel do you think you could check if this is still OK? Are there any other comment? Kind regards, Laurent Bigonville
diff -u cron-3.0pl1/user.c cron-3.0pl1/user.c
--- cron-3.0pl1/user.c
+++ cron-3.0pl1/user.c
@@ -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
@@ -108,13 +106,35 @@
* 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);
+ freeconary(context_list);
+ if (security_deny_unknown() == 0) {
+ return 0;
+ } else {
+ return -1;
+ }
+ }
+
+ access_vector_t bit = string_to_av_perm(tclass, "entrypoint");
+ if (!bit) {
+ log_it(name, getpid(), "Failed to translate av perm entrypoint", tabname);
+ freeconary(context_list);
+ if (security_deny_unknown() == 0) {
+ return 0;
+ } else {
+ return -1;
+ }
+ }
+
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);
