[apparmor] [patch 1/4] utils/aa-unconfined: fix netstat usage, use ss(8) by default

Christian Boltz apparmor at cboltz.de
Fri Dec 30 20:33:20 UTC 2016


Hello,

Am Freitag, 30. Dezember 2016, 10:20:02 CET schrieb Steve Beattie:
> On Fri, Dec 30, 2016 at 02:54:31PM +0100, Christian Boltz wrote:
> > Am Donnerstag, 29. Dezember 2016 schrieb Steve Beattie:

> > > [2] In fact, the version of ss/iproute2 in Ubuntu 14.04 LTS does
> > > not  restrict the listings to network sockets when 'ss -nlp
> > >     --family inet' is invoked.
> > 
> > Nice[tm].
> 
> Yeah. Oh, there's one other caveat with ss(8), on Ubuntu 12.04 LTS,
> the format is different once again and in a way that my patch is not
> able to parse. But 12.04 is only supported for another 4 months or
> so, and the option to use netstat is still there...

Right, and besides that - 2.11 wasn't released yet, so 12.04 users are 
not at risk (yet) even if they download the latest version. (I'd also 
guess that 12.04 won't get SRU'd to AppArmor 2.11 ;-)

Nevertheless, I hope we get 2.11 released before 12.04 goes out of 
support.  (I had hoped for "this year", but you would hate me a bit more 
if I'd ask for that today or tomorrow ;-)

> > Some testing shows that aa-unconfined gives different results with
> > ss and netstat (ss lists more processes). Some digging shows that
> > this seems to be caused by differences in what netstat and ss
> > reports, so it's not an error in aa-unconfined.
> > 
> > The differences on my system are (only listed by ss):
> > - 2749 /usr/sbin/wpa_supplicant not confined
> > - several apache child processes like
> > 
> >   4049 /usr/sbin/httpd-prefork confined by
> >   '/usr/sbin/httpd{,2}-prefork//HANDLING_UNTRUSTED_INPUT
> >   (complain)'> 
> > I wonder if netstat or ss are "more right" ;-)
> 
> My assumption is that ss is more correct. The apache entry actually is
> what demonstrated that the parsing of ss output was a little more
> complicated; in netstat output, it looks like:
> 
>   tcp6       0      0 :::80                   :::*                
> LISTEN      4296/apache2
> 
> whereas in ss, it looks like so:
> 
>   tcp   LISTEN   0   128   :::80   :::*  
> users:(("apache2",pid=22236,fd=4),("apache2",pid=8747,fd=4),("apache2
> ",pid=8746,fd=4),("apache2",pid=8745,fd=4),("apache2",pid=8744,fd=4),(
> "apache2",pid=8743,fd=4),("apache2",pid=4296,fd=4))

Indeed, that looks more interesting[tm] ;-)

> > Another interesting[tm] detail (off-topic here) is:
> >  4464 /usr/bin/python2.7 (/usr/bin/python) not confined
> > 
> > Hmm, this python2.7 process is salt-master. Interestingly,
> > salt-master.service has   ExecStart=/usr/bin/salt-master
> > Any idea why the processes show up as "python2.7" in the
> > processlist?
> 
> Is this with all the patches in the series applied or just this one?
> It's possible that's a change due to reading the /proc/PID/cmdline
> directly rather than using cat. What does the contents of
> /proc/PID/cmdline look like for the salt process? (Note that it's a
> series of strings that are null terminated, so you might want to do
> something like "sed -e 's/\x0/\n/g'" on it).

# cat /proc/2332/cmdline  | sed -e 's/\x0/\n/g'
/usr/bin/python
/usr/bin/salt-master

So it's really listed this way in /proc/*/cmdline for some reason. 
ps aux also agrees, which means it's not specific to aa-unconfined.

Some more testing shows that for example aa-logprof is also displayed as 
"/usr/bin/python3 /usr/sbin/aa-logprof" in ps aux, so it seems to be 
normal and I overlooked this detail in the "ps aux" output for years ;-)


Regards,

Christian Boltz
-- 
> Und jetzt nochmal ohne HTML-Zeuchs... sorry...
Magst Du es vielleicht nochmal versuchen, dann ohne TOFU?
[> Alexander Homberger und Werner Flamme in postfixbuch-users]
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part.
URL: <https://lists.ubuntu.com/archives/apparmor/attachments/20161230/56581a72/attachment.pgp>


More information about the AppArmor mailing list