5

We are encountering a bizarre issue were non-root users are unable to execute any files (scripts or binaries) in certain directories. This transcript demonstrates the issue:

[root@b6 /]# mkdir q
[root@b6 /]# cp /bin/echo .
[root@b6 /]# cp /bin/echo q
[root@b6 /]# chown -R apps q
[root@b6 /]# ./echo ok
ok
[root@b6 /]# ./q/echo ok
ok
[root@b6 /]# su - apps
[apps@b6 ~]$ cd /
[apps@b6 /]$ ./echo ok
ok
[apps@b6 /]$ ./q/echo ok
-bash: ./q/echo: Permission denied
[apps@b6 /]$ ls -ld . echo q q/echo
dr-xr-xr-x. 29 root root  4096 Jun 10 00:34 .
-rwxr-xr-x.  1 root root 28176 Jun 10 00:34 echo
drwxr-xr-x.  2 apps root  4096 Jun 10 00:34 q
-rwxr-xr-x.  1 apps root 28176 Jun 10 00:34 q/echo
[apps@b6 /]# getfacl q q/echo
# file: q
# owner: apps
# group: root
user::rwx
group::r-x
other::r-x

# file: q/echo
# owner: apps
# group: root
user::rwx
group::r-x
other::r-x

[apps@b6 /]$ id
uid=2070(apps) gid=2070(apps) groups=2070(apps) context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
[apps@b6 /]$ uname -a
Linux b6.pdc 2.6.32-358.18.1.el6.x86_64 #1 SMP Wed Aug 28 17:19:38 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
[apps@b6 /]$ df / /q
Filesystem     1K-blocks    Used Available Use% Mounted on
/dev/md2       198166644 4273776 183826596   3% /
/dev/md2       198166644 4273776 183826596   3% /
[apps@b6 /]$ mount 
/dev/md2 on / type ext4 (rw)
...
[apps@b6 /]$ getenforce
Permissive
[apps@b6 /]$ strace q/echo ok
execve("q/echo", ["q/echo", "ok"], [/* 22 vars */]) = -1 EACCES (Permission denied)
dup(2)                                  = 3
fcntl(3, F_GETFL)                       = 0x8002 (flags O_RDWR|O_LARGEFILE)
fstat(3, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 0), ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f237b0a0000
lseek(3, 0, SEEK_CUR)                   = -1 ESPIPE (Illegal seek)
write(3, "strace: exec: Permission denied\n", 32strace: exec: Permission denied
) = 32
close(3)                                = 0
munmap(0x7f237b0a0000, 4096)            = 0
exit_group(1)                           = ?  

Our first thought was selinux, but this is off. Next was noexec on the f/s, but this isn't the case. Our user shell is just regular bash (not restricted).

16
  • 1
    do you use acls? try: getfacl q/echo
    – Grizly
    Jun 10, 2015 at 1:23
  • No acls being used. Will update the question...
    – AgileZebra
    Jun 10, 2015 at 1:25
  • ok, next I would try file /bin/echo and make sure it matches q/echo, then try strace q/echo ok and see what it is doing, or failing to do.
    – Grizly
    Jun 10, 2015 at 1:32
  • 1
    Does anything appear in log files (/var/log/secure, messages, others) when this fails? Could AppArmor be involved? I'm a bit vague about its capabilities but this feels like a restriction it could impose. Jun 10, 2015 at 6:45
  • 1
    What version of Linux is this? Jun 10, 2015 at 6:45

1 Answer 1

0

I rechecked the logs (logging was misconfigured and previously there was no output when tailing messages - thanks Paul) and I've found this:

2015-06-10T12:25:15.547452+00:00 b6 kernel: [tpe] Denied untrusted exec of /q/echo (uid:2070) by /bin/bash (uid:2070), parents: /bin/su (uid:0), /bin/bash (uid:0), /usr/sbin/sshd (uid:0), /usr/sbin/sshd (uid:0), /sbin/init (deleted) (uid:0). Deny reason: directory uid not trusted

It appears we have grsecurity: Trusted Path Execution enabled (perhaps this is default in CentOS 6.6) and the owner of the directory is not trusted. Looks like we just need to add a number of users as trusted, or disable it as required.

1
  • Interesting.. :D Also, glad you fixed it mate. TIL: grsecurity exists.
    – Grizly
    Jun 12, 2015 at 4:29

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .