[uWSGI] why uwsgi invokes /bin/bash

[Michael Ströder]

HI!

I'm using uwsgi for starting WSGI Python apps.

uwsgi itself is started with a systemd unit which also mandates that an
AppArmor profile is load for that unit.

Although I'm using pretty tight AppAmor profiles everything works.

Now I'd like to minimize the (false-positive?) messages AppArmor writes
to the audit service.

For example during start of the systemd unit the following line is
written to audit log:

type=AVC msg=audit(1533736326.584:30): apparmor="DENIED"
operation="exec" profile="web2ldap" name="/bin/bash" pid=1109
comm="uwsgi" requested_mask="x" denied_mask="x" fsuid=29990 ouid=0

Now I really wonder why /bin/bash is accessed at all. The login shell of
this particular system account for the unit is /usr/sbin/nologin.

In AppArmor I could simply mask this log message completely. But I'd
strongly prefer to see it in case an attacker trys to do something bad.

So anything I could tweak in uwsgi.ini to avoid that?

Ciao, Michael.

[Riccardo Magliocchetti]

Post by Michael Ströder
HI!
I'm using uwsgi for starting WSGI Python apps.
uwsgi itself is started with a systemd unit which also mandates that an AppArmor
profile is load for that unit.
Although I'm using pretty tight AppAmor profiles everything works.
Now I'd like to minimize the (false-positive?) messages AppArmor writes to the
audit service.
For example during start of the systemd unit the following line is written to
type=AVC msg=audit(1533736326.584:30): apparmor="DENIED" operation="exec"
profile="web2ldap" name="/bin/bash" pid=1109 comm="uwsgi" requested_mask="x"
denied_mask="x" fsuid=29990 ouid=0
Now I really wonder why /bin/bash is accessed at all. The login shell of this
particular system account for the unit is /usr/sbin/nologin.

You should probably ask the application developers.

[Michael Ströder]

Post by Riccardo Magliocchetti

Post by Michael Ströder
HI!
I'm using uwsgi for starting WSGI Python apps.
uwsgi itself is started with a systemd unit which also mandates that
an AppArmor profile is load for that unit.
Although I'm using pretty tight AppAmor profiles everything works.
Now I'd like to minimize the (false-positive?) messages AppArmor
writes to the audit service.
For example during start of the systemd unit the following line is
type=AVC msg=audit(1533736326.584:30): apparmor="DENIED"
operation="exec" profile="web2ldap" name="/bin/bash" pid=1109
comm="uwsgi" requested_mask="x" denied_mask="x" fsuid=29990 ouid=0
Now I really wonder why /bin/bash is accessed at all. The login shell
of this particular system account for the unit is /usr/sbin/nologin.

You should probably ask the application developers.

I asked my application developer (me) multiple times. ;-)
He insists there's no invocation of /bin/bash in the application.

Another possibility could be systemd doing "something".
But other services like Apache or OpenLDAP's slapd are also started via
systemd like this (but obviously without uwsgi involved) and they don't
invoke /bin/bash.

Ciao, Michael.

[Damjan Georgievski]

Post by Michael Ströder
HI!
I'm using uwsgi for starting WSGI Python apps.
uwsgi itself is started with a systemd unit which also mandates that an
AppArmor profile is load for that unit.
Although I'm using pretty tight AppAmor profiles everything works.
Now I'd like to minimize the (false-positive?) messages AppArmor writes to
the audit service.
For example during start of the systemd unit the following line is written
type=AVC msg=audit(1533736326.584:30): apparmor="DENIED" operation="exec"
profile="web2ldap" name="/bin/bash" pid=1109 comm="uwsgi" requested_mask="x"
denied_mask="x" fsuid=29990 ouid=0
Now I really wonder why /bin/bash is accessed at all. The login shell of
this particular system account for the unit is /usr/sbin/nologin.
In AppArmor I could simply mask this log message completely. But I'd
strongly prefer to see it in case an attacker trys to do something bad.

neither does systemd or uwsgi run bash. but without either the uwsgi
.ini file or the systemd service file it's hard to tell what you're
seeing

[Michael Ströder]

Post by Damjan Georgievski
but without either the uwsgi
.ini file or the systemd service file it's hard to tell what you're
seeing

See below.

Ciao, Michael.

#---------------------------------------------------------------------------
# uwsgi config for web2ldap service
# Ansible managed: ae-dir/master
#---------------------------------------------------------------------------
[uwsgi]
socket = /opt/ae-dir/run/uwsgi/web2ldap/web2ldap.sock
chmod-socket = 666
chdir = /opt/ae-dir/run/uwsgi/web2ldap
module = web2ldap.wsgi:application
stats = 127.0.0.1:9091
manage-script-name = true
master = false
processes = 1
threads = 10
enable-threads = true
buffer-size = 16384
harakiri = 20
plugin = python
log-format = %(addr) - %(user) [%(ltime)] "%(method) %(uri) %(proto)"
%(status) %(size) "%(referer)" "%(uagent)"

#-----------------------------------------------------------------------
# initiate: systemctl enable web2ldap.service
# start: systemctl start web2ldap.service
# get status: systemctl status web2ldap.service
#
# Ansible managed: ae-dir/master
#-----------------------------------------------------------------------

[Unit]
Description=web2ldap
Requires=network.target local-fs.target remote-fs.target
After=local-fs.target remote-fs.target network.target

[Service]
Type=simple
Environment=LDAPNOINIT=1
Environment=PYTHONOPTIMIZE=2
Environment=PYTHONDONTWRITEBYTECODE=1
ExecStart=/usr/sbin/uwsgi --ini /opt/ae-dir/etc/uwsgi/web2ldap.ini
User=ae-dir-web2ldap
Group=ae-dir-web2ldap
Restart=always
KillSignal=SIGQUIT
Type=notify
StandardError=syslog
# various hardening options
PrivateTmp=yes
ProtectSystem=full
ProtectHome=yes
ProtectKernelModules=yes
ProtectKernelTunables=yes
ProtectControlGroups=yes
NoNewPrivileges=yes
MountFlags=private
SystemCallArchitectures=native
RestrictAddressFamilies=AF_INET AF_INET6 AF_UNIX
PrivateDevices=yes
LockPersonality=yes
RestrictRealtime=yes
AppArmorProfile=web2ldap

[Install]
WantedBy=multi-user.target

[Krzysztof Warzecha]

Hi,

May I suggest attaching strace to your systemd unit?

[Service]
ExecStart=/usr/bin/strace -o /tmp/strace -vvfftt -e trace=%process -s
5000 /usr/sbin/uwsgi --ini /opt/ae-dir/etc/uwsgi/web2ldap.ini

With something similar to this you should be able to see in
/tmp/strace what and how / where is executing bash.


If I had to guess, something probably uses system() and you have
/bin/sh linked to bash.