subject /usr/bin/pythonX.X needed in policy? Not really!

Submit your RBAC policies or suggest policy improvements

Moderators: spender, PaX Team

subject /usr/bin/pythonX.X needed in policy? Not really!

Postby timbgo » Mon Feb 01, 2016 9:50 am

Title (added "Not really!" at 2016-02-01 17:59+01:00):
subject /usr/bin/pythonX.X needed in policy? Not really!
(and made shorter, as was too long)

I think I need to debug Getmail, to be able to see if I can decrypt the SSL session when it fetches mail from my IMAPS or POP3S mail hubs (at my hoster and at my providers, respectively).

Pls. see on Gentoo Forums:

How to Decrypt Getmail IMAPS/POP3S sessions?
https://forums.gentoo.org/viewtopic-t-1 ... ml#7874704

In any elders are around, I have deliberately llinked to the second post of mine that I posted there, because there is the Grsecurity permission issue for me to solve.

Reproducing that part here, for more clarity and more ease:

Code: Select all
Feb  1 06:25:45 g0n kernel: [353942.599063] grsec: (miro:U:/) exec of /usr/bin/python2.7 (/usr/bin/python ) by /usr/bin/python2.7[python:27668] uid/euid:1000/1000 gid/egid:1000/1000, parent /bin/bash[bash:3163] uid/euid:1000/1000 gid/egid:1000/1000
...
Feb  1 06:26:38 g0n kernel: [353995.006352] grsec: (miro:U:/) denied socket(inet,stream,tcp) by /usr/bin/python2.7[python:27668] uid/euid:1000/1000 gid/egid:1000/1000, parent /bin/bash[bash:3163] uid/euid:1000/1000 gid/egid:1000/1000


And the python is started at the command line. I will be starting it (probably after I set... I know this by heart by now:

Code: Select all
subject /usr/bin/python2.7 ol {
   /            h
    -CAP_ALL
    bind    disabled
    connect disabled

}


and start grsec learning), in the fashion explained on pages like:

https://marc.info/?l=getmail&m=144502725016279&w=2

Code: Select all
$ python2 -m pdb $(which getmail)
(Pdb) import imaplib
(Pdb) imaplib.Debug = 4
(Pdb) c

because that appears to give complete debugging in Getmail.

I am a little perplexed, because this is the biggest change so far, in my gradm policy.

And so I'm posting this if there be any advanced users to advise me on this.

I do think that the grsec learning is in the order of the day, so I will be going that way. I have such a backup system in place that I am able to roll back very easily my complete system, so it's not worth for me to wait but rather give it a try even if I need to roll back later.
Will be back to either see if any advice was given, or post my new policy.

Regards!.
Miroslav Rovis
http://www.CroatiaFidelis.hr
Last edited by timbgo on Mon Feb 01, 2016 1:07 pm, edited 3 times in total.
timbgo
 
Posts: 295
Joined: Tue Apr 16, 2013 9:34 am
Location: Zagreb, Croatia

Re: subject /usr/bin/pythonX.X needed in my RBAC policy?

Postby timbgo » Mon Feb 01, 2016 11:04 am

No, I don't think this is normal, whichever the cause of it. Pls. see the Gentoo Forums topic already linked, but this post:

https://forums.gentoo.org/viewtopic-t-1 ... ml#7874746

In short, it's either a bug (Gentoo has had some rought times lately, and I'm on ~amd64, which is the testing mode), or I did something wrong, or, don't know.

Because the python command should give the interface just find, without any learning, IIUC...
timbgo
 
Posts: 295
Joined: Tue Apr 16, 2013 9:34 am
Location: Zagreb, Croatia

Re: subject /usr/bin/pythonX.X needed in my RBAC policy?

Postby timbgo » Mon Feb 01, 2016 11:51 am

Just to confirm that it is an RBAC policiy issue. If I disable gradm, then, I can normally use the python command:
Code: Select all
$ python2 -m pdb $(which getmail)
> /usr/bin/getmail(11)<module>()
-> from __future__ import with_statement
(Pdb)
timbgo
 
Posts: 295
Joined: Tue Apr 16, 2013 9:34 am
Location: Zagreb, Croatia

Re: subject /usr/bin/pythonX.X needed in my RBAC policy?

Postby timbgo » Mon Feb 01, 2016 12:26 pm

I think I understood the problem sufficiently to solve it. I now have a working python2 interface, as needed for getmail debugging.

The change was, apparently (at least after that change it now works), needed in the root subject /bin/bash, which looked like this:

Code: Select all
# Role: root
subject /bin/bash o {
   /            
   /Cmn            wc
   /Cmn/gX*            rwxcdl
   /Cmn/Kaff         rwxcd
   /bin            x
   /boot            h
   /dev            
   /dev/grsec         h
   /dev/kmem         h
   /dev/log         h
   /dev/mem         h
   /dev/null         w
   /dev/port         h
   /dev/tty         rw
   /etc            r
   /etc/bash         h
   /etc/bash/bash_logout      r
   /etc/bash/bashrc      r
   /etc/bash/bashrc.d      
   /etc/cron.hourly      
   /etc/grsec         h
   /etc/gshadow         h
   /etc/gshadow-         h
   /etc/init.d         
   /etc/java-config-2      h
   /etc/java-config-2/current-system-vm   
   /etc/mactab         w
   /etc/postfix         wc
   /etc/profile.d         
   /etc/profile.d/java-config-2.sh   r
   /etc/shadow         h
   /etc/shadow-         h
   /etc/ssh         h
   /etc/terminfo         
   /etc/terminfo/l/linux      r
   /etc/terminfo/r/rxvt-unicode   r
   /export            rwxcd
   /home            
   /home/miro         rw
   /lib64            rx
   /lib64/modules         h
   /mnt            
   /proc            r
   /proc/bus         h
   /proc/kallsyms         h
   /proc/kcore         h
   /proc/modules         h
   /proc/slabinfo         h
   /proc/sys         
   /proc/sys/kernel      
   /proc/sys/kernel/grsecurity      w
#   /proc/sys/kernel/grsecurity/audit_chdir   w
#   /proc/sys/kernel/grsecurity/exec_logging   w
   /proc/sys/net/netfilter      w
#   /proc/sys/net/netfilter/nf_conntrack_timestamp   w
   /root            rwcdl
   /run            
   /sbin            x
   /sys            h
   /tmp            rwcd
   /usr            
   /usr/bin         x
   /usr/lib64         h
   /usr/lib64/gconv/gconv-modules.cache   r
   /usr/lib64/locale/locale-archive   r
   /usr/lib64/python-exec/python-exec2   x
   /usr/libexec/eselect-java/run-java-tool.bash   r
   /usr/local         r   
   /usr/local/bin      rx   
   /usr/sbin         x
   /usr/sbin/sendmail   rx
   /usr/share         h
   /usr/share/info      r
   /usr/share/locale      r
   /usr/share/terminfo      r
   /usr/src         rwxc
   /usr/x86_64-pc-linux-gnu   
   /usr/x86_64-pc-linux-gnu/binutils-bin   h
   /usr/x86_64-pc-linux-gnu/binutils-bin/2.25.1   x
   /usr/x86_64-pc-linux-gnu/gcc-bin   
   /var            
   /var/lib         
   /var/lib/clamav         
   /var/lib/portage      
   /var/spool         
   -CAP_ALL
   +CAP_CHOWN
   +CAP_DAC_OVERRIDE
   +CAP_DAC_READ_SEARCH
   +CAP_FOWNER
   +CAP_KILL
   +CAP_SYS_ADMIN
   bind   disabled
   connect   disabled
}

and the change that just got it working is:
Code: Select all
# diff grsec_160201_g0n_00 grsec_160201_g0n_01
682a683
>    /usr/lib64/python-exec/python-exec2-c   x

In other words, that line was missing previously.

How I arrived at that solution? I read the old policy for the subjects that featured the binaries of this story, and figured out what was missing...

My /etc/grsec/policy, even though by this time it differs in ever more details, from then, is still based on what I posted here:

A no-poetterware desktop RBAC policy
viewtopic.php?f=5&t=4153

when I first installed it,

I can now dedicate to try and get those getmail SSL sessions decrypted for my eyes only ;-) .

Regards!
Miroslav Rovis
http://www.CroatiaFidelis.hr
timbgo
 
Posts: 295
Joined: Tue Apr 16, 2013 9:34 am
Location: Zagreb, Croatia


Return to RBAC policy development