On ma, 03 joulu 2018, Levin Stanislav wrote:
Hello All.
I'm planning to run gssproxy as a non-privileged user (say _gssproxy).
I see that there is such possibility via "run_as_user".
Moreover, I want to deliver this as default to my distro.
The expected gssproxy's clients are FreeIPA, NFS-{server,client} with
their default gssproxy configs.
So, i've checked against FreeIPA.
It seems that works, but there is an error message:
```
gssproxy[9862]: Unexpected failure in realpath: 13 (Permission denied)
```
Which come from:
```
lstat("/proc", {st_mode=S_IFDIR|0555, st_size=0, ...}) = 0
lstat("/proc/4054", {st_mode=S_IFDIR|0555, st_size=0, ...}) = 0
lstat("/proc/4054/exe", {st_mode=S_IFLNK|0777, st_size=0, ...}) = 0
readlink("/proc/4054/exe", 0x7ffe7dbf5ee0, 4095) = -1 EACCES (Permission
denied)
```
As I understood from man page and code a canonical path to a program is
used to whether allow service access to gssproxy or not.
Please, consider next code:
```
struct gp_service *gp_creds_match_conn(struct gssproxy_ctx
*gpctx,
struct gp_conn
*conn)
{
struct gp_creds
*gcs;
const char
*socket;
const char
*program;
gcs =
gp_conn_get_creds(conn);
socket =
gp_conn_get_socket(conn);
program =
gp_conn_get_program(conn);
for (int i = 0; i < gpctx->config->num_svcs; i++)
{
struct gp_service *svc =
gpctx->config->svcs[i];
if ((!svc->any_uid && svc->euid != gcs->ucred.uid)
||
!gp_conn_check_selinux(conn, svc->selinux_ctx)
||
(svc->program && !gp_same(program, svc->program))
||
(svc->socket && !gp_same(socket, svc->socket))
||
(!svc->socket && !gp_same(socket,
gpctx->config->socket_name))) {
continue;
}
GPDEBUGN(2, "Connection matched service %s\n",
svc->name);
return
svc;
}
GPDEBUGN(2, "No matching service
found\n");
return
NULL;
}
```
The pattern 'program = /a/b/c' will not work in such a case because
"program" pointer is always 0x0.
For now this is no problem for FreeIPA, NFS. But in future there may be
new clients of gssproxy.
So, my question are there any other known limitations of utilization of
gssproxy non-privileged user?
If you'd allow PTRACE_MODE_READ_FSCREDS to
_gssproxy user-based
execution, it should work with the original code (see ptrace(2)).
Unfortunately, there is no way to differentiate various ptrace modes in
systemd, so you'd need
AmbientCapabilities=CAP_SYS_PTRACE
in gssproxy's systemd service file.
--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland