[gentoo-hardened] Questions about SELinux

[Robert Sharp]

Hi there,

is this the best place to raise questions about SELinux, or would I be 
better trying chat? I am making a big effort to get to enforcing strict 
on a simple server and I am struggling a little.


For example, I run Rsyslog and I have lots of AVCs concerning denied 
sendto's to /dev/log. The target context is usually sysadm_t, which does 
not seem right, and I also notice that Rsyslog is in the same context. I 
would expect it to be in a context involving syslog somehow. I have 
restarted the service from the sysadm_r role and it makes no difference. 
Also, I do not get asked to authenticate when starting the service, 
whereas other services require this, and, there is no entry for rsyslog 
in rc-status display despite it being installed in the default runlevel.


Example AVCs:

type=AVC msg=audit(1478957011.808:1910): avc:  denied  { sendto } for  
pid=6043 comm="smtp" path="/dev/log" 
scontext=system_u:system_r:postfix_smtp_t 
tcontext=staff_u:sysadm_r:sysadm_t tclass=unix_dgram_socket permissive=1


type=AVC msg=audit(1478953126.199:1909): avc:  denied  { sendto } for  
pid=5949 comm="cleanup" path="/dev/log" 
scontext=system_u:system_r:postfix_cleanup_t 
tcontext=staff_u:sysadm_r:sysadm_t tclass=unix_dgram_socket permissive=1


type=AVC msg=audit(1478952507.872:1907): avc:  denied  { sendto } for  
pid=3099 comm="krb5kdc" path="/dev/log" 
scontext=system_u:system_r:krb5kdc_t tcontext=staff_u:sysadm_r:sysadm_t 
tclass=unix_dgram_socket permissive=1



There does not appear to be any specific rsyslog selinux package so I 
assume it should all be syslog-related and already in the core policy 
(although I cannot find it there). I also note that Red Hat has a page 
on setting up Rsyslog in SELinux so I feel fairly sure it should work. 
It only tells you how to change the ports, however. I am using TCP on 
port 514 but I don't think I need to do anything according to RH.


Have I missed something, done something fundamentally wrong, or just 
need to add something to stop the AVCs? Not keen on blindly fixing 
things so I want to know what I need to do and why before I do it.


Thanks in anticipation,
Robert Sharp

[gentoo-hardened] Portage-related AVCs

[Robert Sharp]

Hi,

just done my weekly update and I noticed the following AVCs occurred 
that suggest something missing in the portage policy?


type=PROCTITLE msg=audit(1479900756.052:3548): 
proctitle=6370002D61002D2D7265666C696E6B3D6175746F002F7661722F746D702F706F72746167652F6465762D707974686F6E2F70797061782D302E392E322F696D6167652F5F707974686F6E322E372F2E002F7661722F746D702F706F72746167652F6465762D707974686F6E2F70797061782D302E392E322F696D6167652F2F
type=PATH msg=audit(1479900756.052:3548): item=0 
name="/var/tmp/portage/dev-python/pypax-0.9.2/image/." inode=1182893 
dev=fd:00 mode=040755 ouid=0 ogid=0 rdev=00:00 
obj=staff_u:object_r:portage_tmp_t nametype=NORMAL
type=CWD msg=audit(1479900756.052:3548): 
cwd="/var/tmp/portage/dev-python/pypax-0.9.2/work/elfix-0.9.2/scripts"
type=SYSCALL msg=audit(1479900756.052:3548): arch=c03e syscall=189 
success=yes exit=0 a0=44b69d9c40 a1=36fe2f5a763 a2=44b69d9df0 a3=1f 
items=1 ppid=21441 pid=21661 auid=4294967295 uid=0 gid=0 euid=0 suid=0 
fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=4294967295 comm="cp" 
exe="/bin/cp" subj=staff_u:sysadm_r:portage_sandbox_t key=(null)
type=AVC msg=audit(1479900756.052:3548): avc:  denied  { relabelto } 
for  pid=21661 comm="cp" name="image" dev="dm-0" ino=1182893 
scontext=staff_u:sysadm_r:portage_sandbox_t 
tcontext=staff_u:object_r:portage_tmp_t tclass=dir permissive=1
type=AVC msg=audit(1479900756.052:3548): avc:  denied  { relabelfrom } 
for  pid=21661 comm="cp" name="image" dev="dm-0" ino=1182893 
scontext=staff_u:sysadm_r:portage_sandbox_t 
tcontext=staff_u:object_r:portage_tmp_t tclass=dir permissive=1


I checked the policy for source=portage_sandbox_t and 
target=portage_tmp_t and it is:


# sesearch -s portage_sandbox_t -t portage_tmp_t -Ad
Found 5 semantic av rules:
   allow portage_sandbox_t portage_tmp_t : lnk_file { ioctl read write 
create getattr setattr lock unlink link rename } ;
   allow portage_sandbox_t portage_tmp_t : dir { ioctl read write 
create getattr setattr lock unlink link rename add_name remove_name 
reparent search rmdir open } ;
   allow portage_sandbox_t portage_tmp_t : fifo_file { ioctl read write 
create getattr setattr lock append unlink link rename open } ;
   allow portage_sandbox_t portage_tmp_t : file { ioctl read write 
create getattr setattr lock relabelfrom relabelto append unlink link 
rename execute execute_no_trans open } ;
   allow portage_sandbox_t portage_tmp_t : sock_file { ioctl read write 
create getattr setattr lock append unlink link rename open } ;


It looks to me like portage was trying to relabelto/from a directory but 
these ops are only allowed for files?


I also spotted AVCs involving directory access to portage_tmpfs_t (and 
sandbox as the source), such as:


type=PROCTITLE msg=audit(1479900586.938:3542): 
proctitle=707974686F6E322E37002F7573722F6C696236342F707974686F6E322E372F736974652D7061636B616765732F696E636C7564655F7365727665722F696E636C7564655F7365727665722E7079002D2D706F7274002F746D702F6469737463632D70756D702E656B6A3330372F736F636B6574002D2D7069645F66696C65002F
type=PATH msg=audit(1479900586.938:3542): item=1 
name="/dev/shm/tmpgk84Lo.include_server-16244-1" inode=1246573 dev=00:13 
mode=040700 ouid=250 ogid=250 rdev=00:00 
obj=staff_u:object_r:portage_tmpfs_t nametype=DELETE
type=PATH msg=audit(1479900586.938:3542): item=0 name="/dev/shm/" 
inode=8351 dev=00:13 mode=041777 ouid=0 ogid=0 rdev=00:00 
obj=system_u:object_r:tmpfs_t nametype=PARENT
type=CWD msg=audit(1479900586.938:3542): 
cwd="/var/tmp/portage/dev-python/cffi-1.5.2/work/cffi-1.5.2"
type=SYSCALL msg=audit(1479900586.938:3542): arch=c03e syscall=84 
success=yes exit=0 a0=3a6d7c7770 a1=0 a2=0 a3=36b items=2 ppid=1 
pid=16244 auid=4294967295 uid=250 gid=250 euid=250 suid=250 fsuid=250 
egid=250 sgid=250 fsgid=250 tty=pts0 ses=4294967295 comm="python2.7" 
exe="/usr/bin/python2.7" subj=staff_u:sysadm_r:portage_sandbox_t key=(null)
type=AVC msg=audit(1479900586.938:3542): avc:  denied  { rmdir } for  
pid=16244 comm="python2.7" name="tmpgk84Lo.include_server-16244-1" 
dev="tmpfs" ino=1246573 scontext=staff_u:sysadm_r:portage_sandbox_t 
tcontext=staff_u:object_r:portage_tmpfs_t tclass=dir permissive=1


And a similar AVC for creating the same directory.

Is this likely to be a policy gap or have I done something wrong or 
failed to do something I should have. I cannot provide more details 
about what was happening at the time, other than in the audit snippets 
above - it was the middle of a lengthy update process.


Thanks,

Robert Sharp

Re: [gentoo-hardened] Portage-related AVCs

[Robert Sharp]

On 23/11/16 14:37, Jason Zaman wrote:

Are you on ~arch or stable? did you just upgrade to the 2.6 userland?
What versions do you have installed of these:
sys-libs/libsepol
sys-libs/libselinux
sys-libs/libsemanage
sys-apps/checkpolicy
sys-apps/policycoreutils
dev-python/sepolgen
app-admin/setools

Looks like I am stable - 2.5 for all of the above.


what does this return?
ls -al/etc/selinux/*/policy/policy.*
-rw-r--r--. 1 root root 48 Apr  6  2016 
/etc/selinux/strict/policy/policy.29
-rw-r--r--. 1 root root 445097 Nov 23 11:43 
/etc/selinux/strict/policy/policy.30
-rw-r--r--. 1 root root 450378 Apr  6  2016 
/etc/selinux/targeted/policy/policy.29
-rw-r--r--. 1 root root 462377 Nov 23 11:43 
/etc/selinux/targeted/policy/policy.30

and in /etc/selinux/semanage.conf, do you have policy-version =  set to 
anything?

module-store = direct
save-linked=false
expand-check=1
bzip-blocksize=0
bzip-small=true

so no for the last one!

Should I move to ~arch then, and is there a guide for that or is it 
fairly simple?


Thanks,
Robert

Re: [gentoo-hardened] Portage-related AVCs

[Robert Sharp]

On 23/11/16 15:58, Jason Zaman wrote:

Either is fine, but im probably just gonna stabilize the 2.6 userspace
in a couple weeks so that one is likely easier. and setools4 is waaay
better than 3. The important point is that you dont want to have both
policy.29 and policy.30 around. Then you get weirdness like if you
downgrade a kernel or something random it'll load in the old policy
which probably doesnt work properly, so whichever you pick, make sure
you nuke the other one. and semodule -B will rebuild the whole policy
again and load it.
OK - I will go with policy.30 and add the keywords etc. I did a couple 
of local policy changes that may not be needed so will they disappear in 
all of this or do I need to remove them somehow first?


Thanks for all your help,
Robert

Re: [gentoo-hardened] Portage-related AVCs

[Robert Sharp]

On 23/11/16 16:59, Robert Sharp wrote:


On 23/11/16 15:58, Jason Zaman wrote:

Either is fine, but im probably just gonna stabilize the 2.6 userspace
in a couple weeks so that one is likely easier. and setools4 is waaay
better than 3. The important point is that you dont want to have both
policy.29 and policy.30 around. Then you get weirdness like if you
downgrade a kernel or something random it'll load in the old policy
which probably doesnt work properly, so whichever you pick, make sure
you nuke the other one. and semodule -B will rebuild the whole policy
again and load it.
OK - I will go with policy.30 and add the keywords etc. I did a couple 
of local policy changes that may not be needed so will they disappear 
in all of this or do I need to remove them somehow first?


Thanks for all your help,
Robert


Sorry - noticed a couple of things while preping the emerge:

1) selinux-base-policy is blocking policycoreutils so presumably I need 
to add that to my accept_keywords?
2) this package has the "unconfined" use flag set but I don't use 
unconfined. Does that matter?


Thanks again,
Robert

Re: [gentoo-hardened] Portage-related AVCs

[Robert Sharp]

On 23/11/16 17:30, Jason Zaman wrote:

On Wed, Nov 23, 2016 at 05:20:59PM +, Robert Sharp wrote:

On 23/11/16 16:59, Robert Sharp wrote:

On 23/11/16 15:58, Jason Zaman wrote:

Either is fine, but im probably just gonna stabilize the 2.6 userspace
in a couple weeks so that one is likely easier. and setools4 is waaay
better than 3. The important point is that you dont want to have both
policy.29 and policy.30 around. Then you get weirdness like if you
downgrade a kernel or something random it'll load in the old policy
which probably doesnt work properly, so whichever you pick, make sure
you nuke the other one. and semodule -B will rebuild the whole policy
again and load it.

OK - I will go with policy.30 and add the keywords etc. I did a couple
of local policy changes that may not be needed so will they disappear
in all of this or do I need to remove them somehow first?

Thanks for all your help,
Robert


Sorry - noticed a couple of things while preping the emerge:

1) selinux-base-policy is blocking policycoreutils so presumably I need
to add that to my accept_keywords?
2) this package has the "unconfined" use flag set but I don't use
unconfined. Does that matter?

Oh, yeah the 2.6 userland needs at minimum 2.20151208-r6. Its been long
enough, i'll stabilize the new policies right away so just wait a bit
any sync again.

unconfined useflag just builds it, if you are using strict you can turn
off unconfined and set this in make.conf:
POLICY_TYPES="strict"
then it wont even build the targetted modules at all.

Thanks Jason - you have been busy. I have just updated to 20151208-r6 
and when I run semodule -B I get this message:


  "libsemanage.add_user: user system_u not in password file"

Googling suggests this was a problem in Fedora (see bug 
https://bugzilla.redhat.com/show_bug.cgi?id=1378204) and it was fixed a 
few days ago in their selinux-policy-3.13.1-191.20.fc24. I ran sesearch 
as before and it comes up with the same results as before so I assume 
the semodule command did not do what it was supposed to do. Is there a 
work around for this or should I go ~arch on the policy as well? If so, 
is there a way to avoid listing all the policy packages in my 
accept_keywords file?


Thanks again,
Robert

Re: [gentoo-hardened] Portage-related AVCs

[Robert Sharp]

On 24/11/16 17:07, Jason Zaman wrote:

That warning is harmless, i'll remove the line from the policy later.
for now ignore it or manually remove the line to silence the warning.
http://blog.perfinion.com/2016/10/selinux-userspace-26-released/


Sorry Jason, but I am not making much progress. I have emerged as you 
suggested with the 20151208-r6 versions (and setools4). When I repeat 
the search for portage_sandbox I get the same results as before:


# sesearch -s portage_sandbox_t -t portage_tmp_t -A
allow portage_sandbox_t non_auth_file_type:dir { search read lock 
getattr ioctl open };
allow portage_sandbox_t non_auth_file_type:file { read lock ioctl open 
getattr };

allow portage_sandbox_t non_auth_file_type:lnk_file { read getattr };
allow portage_sandbox_t portage_tmp_t:dir { rename search setattr read 
lock create reparent getattr write ioctl link rmdir remove_name unlink 
open add_name };
allow portage_sandbox_t portage_tmp_t:fifo_file { rename setattr read 
lock create getattr write ioctl link unlink open append };
allow portage_sandbox_t portage_tmp_t:file { rename execute setattr read 
lock create getattr execute_no_trans write relabelfrom ioctl link 
relabelto unlink open append };
allow portage_sandbox_t portage_tmp_t:lnk_file { rename setattr read 
lock create getattr write ioctl link unlink };
allow portage_sandbox_t portage_tmp_t:sock_file { rename setattr read 
lock create getattr write ioctl link unlink open append };


There is still no relableto/from in the dir rule. I am not sure the 
module rebuild worked. I tried the semodule -B again with -v and it all 
happens rather quickly:


# semodule -B -v
Committing changes:
libsemanage.add_user: user system_u not in password file
Ok: transaction number 0.

Doesn't seem like it spent long rebuilding all those policies, but then 
I wouldn't know if it is supposed to be quick?


Also, there doesn't seem to be a very easy way to confirm what policy 
version is in place? I once saw a listing from semodule -l that included 
version information but it doesn't happen on my system.


Robert

[gentoo-hardened] SELinux and rkhunter

[Robert Sharp]

Hi,

I can run rkhunter as root with role sysadm_r and there are no issues, 
but when I run it from a cron job I get lots of AVCs because the source 
context is system_cronjob_t. I am using vixie-cron and running rkhunter 
from a crontab in /etc/cron.d/.


I can see 2 options for fixing this:

1) set the label on the crontab to be the same as when I run rkhunter 
with no AVCs (sysadm_r). Not sure if this happens with a system crontab. 
I would need to set the boolean cron_userdomain_transition to true, and 
it would end up with a crontab file having a different label to that 
specified by the policy.


2) create an intermediate script that I run from the crontab, that 
itself runs rkhunter and effects a transition to the sysadm_t context 
before doing so. I would need to write a short policy to do this and 
allow system_cronjob_t to make the transition. This looks like the 
better route to go.


Does anyone have any views about the best way to proceed or whether to 
do this at all?


Thanks

Robert Sharp

Re: [gentoo-hardened] SELinux and rkhunter

[Robert Sharp]

On 25/11/16 11:51, Jason Zaman wrote:

Ideally, rkhunter should just have a policy.
It would need something like: cron_system_entry(rkhunter_t, rkhunter_exec_t)
If you wanted to write one, basing it off the aide policy would probably
help.
https://gitweb.gentoo.org/proj/hardened-refpolicy.git/tree/policy/modules/contrib/aide.te
Its quite a simple policy, it pretty much just needs to read everything
on disk.


Well, I want to learn more about SELinux so writing and testing a 
"proper" policy sounds like an idea. I will give it a go.


Robert

[gentoo-hardened] Policies and Ports - how to define access?

[Robert Sharp]

Hi,


I've looked at the Gentoo SELinux web pages etc, the SELinux Handbook 
and through the Reference Policy and I cannot find the answer to a 
simple question.


I am writing a small policy for my backup system and I want to be able 
to a) access a MongoDB running on remote servers, and b) use rsync. I 
can see two AVCs relating to my port use and I know how I can fix the 
problem from the command line, but surely I should be able to address 
this in the policy? I think there is an rsync interface I need to call 
(rsync_entry_type(mytype_t)) and I assume this will run rsync in the 
right domain?


Mongo has a policy but the only interface is admin. All I need to do 
locally is connect to the port. Can I use "portcon" in a policy to do 
this or do I need to do something else?


Thanks,

Robert Sharp

Re: [gentoo-hardened] Policies and Ports - how to define access?

[Robert Sharp]

On 01/12/16 15:31, Jason Zaman wrote:

On Thu, Dec 01, 2016 at 10:24:21AM +, Robert Sharp wrote:

Hi,


I've looked at the Gentoo SELinux web pages etc, the SELinux Handbook
and through the Reference Policy and I cannot find the answer to a
simple question.

I am writing a small policy for my backup system and I want to be able
to a) access a MongoDB running on remote servers, and b) use rsync. I
can see two AVCs relating to my port use and I know how I can fix the
problem from the command line, but surely I should be able to address
this in the policy? I think there is an rsync interface I need to call
(rsync_entry_type(mytype_t)) and I assume this will run rsync in the
right domain?

Mongo has a policy but the only interface is admin. All I need to do
locally is connect to the port. Can I use "portcon" in a policy to do
this or do I need to do something else?

Thanks,

Robert Sharp

What port number is it using? does that port already have a label? if it
does then you use the corenet stuff, eg:

corenet_tcp_connect_mysqld_port(foo_t) would allow foo_t to connect to
these ports:

#  semanage port -l | grep mysql
mysqld_port_t  tcp  1186, 3306, 63132-63164

if there is no good label on the port currently, you can define your own
with semanage port. or it can be added to the base policy, because of
the way pp files work, you cannot do portcon in a module. If there is a
port that is missing a label, we can add it to the base in both refpol
and gentoos policy.

Look at policy/modules/kernel/corenetwork.te.in in the policy for
adding a new one.

As for rsync, if you want your script to be able to run it without
changing domain, you probably want rsync_exec(), if you want to transition
to rsync_t, then rsync_domtrans()

-- Jason

Mongo uses tcp on port 27017 and there is nothing defined for this in 
the core policy. There is a mongodb policy in contrib but it uses 
corenet_all_recvfrom_unlabeled, corenet_tcp_sendrecv_generic_if and the 
likes.


From what I can make out, semanage port will only allow me to assign a 
port to an existing label? Looks like I can only define a port label in 
the reference policy? What is the best way forward? If I was to add 
something to corenetwork.te it would look like this, I guess:


type mongodb_port_t, port_type, defined_port_type;
type mongodb_client_packet_t, packet_type, client_packet_type;
type mongodb_server_packet_t, packet_type, server_packet_type;
typeattribute mongodb_port_t unreserved_port_type;
portcon tcp 27017 gen_context(system_u:object_r:mongodb_port_t,s0)

Would that then create a "corenet_tcp_connect_mongodb_port" interface?

Incidentally, if I have a little family of apps that use use a number of 
unreserved ports. Seems a little monolithic if the only way I can 
integrate them is to have them included in the base policy? Luckily they 
are not on the machine I am trying to get to strict atm, but they are on 
the next one.


Thanks for your help, as always!

Robert

Re: [gentoo-hardened] Policies and Ports - how to define access?

[Robert Sharp]

On 03/12/16 10:16, Sven Vermeulen wrote:

On Fri, Dec 02, 2016 at 12:05:50PM +, Robert Sharp wrote:

Mongo uses tcp on port 27017 and there is nothing defined for this in
the core policy. There is a mongodb policy in contrib but it uses
corenet_all_recvfrom_unlabeled, corenet_tcp_sendrecv_generic_if and the
likes.

I know you can't define a port mapping in the "legacy" (for lack of a better
name, call it .pp or so if you want ;) approach, but can't we define a port
type in a module, and then use the 'semanage port' command to map it to the
right port?

Another approach that works is to create your port definition with CIL. See
the following two posts (the CIL code is in the first, loading in the second
as the first post didn't know yet they were directly loadable):

http://blog.siphos.be/2015/06/where-does-cil-play-in-the-selinux-system/
http://blog.siphos.be/2015/07/loading-cil-modules-directly/

Wkr,
Sven Vermeulen

Thanks for this. I wrote a little CIL snippet based on your example for 
27017 and semodule'd it in. I could then see the port with semanage port 
-l and I could use it in the .te file as well. I made a mistake first 
time round by naming the .cil file the same as the others, which create 
mayhem when I tried importing the module. I removed the .cil bit, 
renamed it mongodb.cil and tried again. This time it worked. I guess I 
ought to look at the mongodb in contrib to see if there should be a 
client side to the policy, and perhaps rename my CIL to something like 
mongodb_port.cil.


Is there a plan to move everything to CIL? It is just that you referred 
to the .pp approach as "legacy". I just wonder because CIL looks fairly 
unfriendly and may even be an intermediate language. Also, are there any 
plans to make the whole thing more modular? Looking at corenetwork.if, 
for example, is a bit of a surprise.


Best regards,

Robert

[gentoo-hardened] Ddclient sending emails on a Postfix server

[Robert Sharp]

I am running ddclient on my router together with a relaying postfix 
server. Unfortunately I have configured ddclient to send emails when it 
has problems and I have had quite a few problems with AVCs as a result. 
I have figured most of them out now but there is one that I am stuck on.


It appears that sendmail (postfix variant) calls postdrop to actually 
deliver the emails, and using the 
postfix_domtrans_user_mail_handler(ddclient_t)
interface fixes most of the AVCs except two, and this is where I am 
stuck. Here is the ausearch output:


type=PROCTITLE msg=audit(1481006916.953:34919): 
proctitle=2F7573722F7362696E2F706F737464726F70002D72
type=PATH msg=audit(1481006916.953:34919): item=1 
name="/lib64/ld-linux-x86-64.so.2" inode=1478356 dev=fd:00 mode=0100755 
ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:ld_so_t nametype=NORMAL
type=PATH msg=audit(1481006916.953:34919): item=0 
name="/usr/sbin/postdrop" inode=818771 dev=fd:00 mode=0102711 ouid=0 
ogid=208 rdev=00:00 obj=system_u:object_r:postfix_postdrop_exec_t 
nametype=NORMAL

type=CWD msg=audit(1481006916.953:34919): cwd="/var/spool/postfix"
type=EXECVE msg=audit(1481006916.953:34919): argc=2 
a0="/usr/sbin/postdrop" a1="-r"
type=SYSCALL msg=audit(1481006916.953:34919): arch=c03e syscall=59 
success=yes exit=0 a0=5b97747f30 a1=5b97748d70 a2=5b97747e50 a3=20 
items=2 ppid=24964 pid=24965 auid=103 uid=103 gid=246 euid=103 suid=103 
fsuid=103 egid=208 sgid=208 fsgid=208 tty=(none) ses=7 comm="postdrop" 
exe="/usr/sbin/postdrop" subj=system_u:system_r:postfix_postdrop_t 
key=(null)
type=AVC msg=audit(1481006916.953:34919): avc:  denied  { read write } 
for  pid=24965 comm="postdrop" path="socket:[2916040]" dev="sockfs" 
ino=2916040 scontext=system_u:system_r:postfix_postdrop_t 
tcontext=system_u:system_r:ddclient_t tclass=unix_stream_socket permissive=1


time->Tue Dec  6 06:48:36 2016
type=AVC msg=audit(1481006916.965:34920): avc:  denied  { getattr } for  
pid=24965 comm="postdrop" path="socket:[2916040]" dev="sockfs" 
ino=2916040 scontext=system_u:system_r:postfix_postdrop_t 
tcontext=system_u:system_r:ddclient_t tclass=unix_stream_socket permissive=1


The command "postdrop -r" reads a message from stdin and writes a 
response to stdout. I am guessing these socket permissions are to do 
with piping stdout back to sendmail (running in ddclient_t), but I would 
have expected a fifo_file on a pipe rather than a socket? I can always 
check this with the postfix forum if needed.


I guess the "wrong" solution would be to require postfix_postdrop_t and 
allow it to access ddclient_t etc, but that would violate the rules, so 
either the postdrop interface is wrong or perhaps I should be doing this 
without a domain transition. That is how I started out and I had a whole 
lot more AVCs that are fixed by the transition, so I am tending towards 
the postdrop interface being not quite right?


Any views would be very much appreciated.

Best wishes,

Robert Sharp

[gentoo-hardened] SELinux sysnetwork policy update?

[Robert Sharp]

Just updated all my SELinux policies to 20161023-r1 as they are now 
stable, which undid one little fix, so I thought I would mention it.


Sysnetwork.te does not cover the possibility that dhcpcd may run 
resolvconf from the dhcpc_script_t domain, which it seems is how my 
dhcpcd works. This is fixed by adding:


optional_policy(`
resolvconf_client_domain(dhcpc_script_t)
')

to the dhcpc_script policy (end of the file). It seems like a reasonable 
addition, given the same policy applies to the dhcpc_t domain.


Not sure if this sort of proposal should be filed as a bug or just 
raised here?


Robert Sharp

Re: [gentoo-hardened] SELinux sysnetwork policy update?

[Robert Sharp]

On 10/12/16 06:19, Jason Zaman wrote:



On 9 Dec 2016 16:29, "Robert Sharp" <mailto:seli...@sharp.homelinux.org>> wrote:


Just updated all my SELinux policies to 20161023-r1 as they are
now stable, which undid one little fix, so I thought I would
mention it.

Sysnetwork.te does not cover the possibility that dhcpcd may run
resolvconf from the dhcpc_script_t domain, which it seems is how
my dhcpcd works. This is fixed by adding:

optional_policy(`
resolvconf_client_domain(dhcpc_script_t)
')

to the dhcpc_script policy (end of the file). It seems like a
reasonable addition, given the same policy applies to the dhcpc_t
domain.

Not sure if this sort of proposal should be filed as a bug or just
raised here?

Robert Sharp

Can you file a bug on bugs.gentoo.org <http://bugs.gentoo.org> and say 
this and also list the AVCs you get from audit.log?


I have already prepared the -r2 release just haven't pushed it to the 
repo yet so I probably won't add to that cuz I don't want to do it 
last min. The -r2 policies will be out as soon as I figure out why the 
4.8 kernel isn't booting for me.


Thanks!
Jason


Hi Jason,

Just filing the bug and I realise I did not save any AVCs relating to 
dhcpc_script_t, but only those for resolvconf itself. It would be useful 
to include the former but to do that I need to unwind my locally patched 
policy. I know I can use semodule -r to remove the patched module, but 
how do I get the original policy re-instated given it is part of the 
core? I guess I could create another local module from my git clone and 
load that?


Thanks,

Robert

Re: [gentoo-hardened] Ddclient sending emails on a Postfix server

[Robert Sharp]

On 12/12/16 20:03, Sven Vermeulen wrote:

It's been a while that I did some Postfix work, which might be necessary to
debug this properly. The socket is owned by ddclient, is it possible that
"postdrop -r" input and/or output is redirected to a ddclient socket? From a
quick Google ddclient is shown as a Perl client, so some code scanning might
help to find out what the socket is about.


Yes, ddclient is one long perl script. I am not a perl diver myself but 
it is not difficult to track down the code. The "sub" routine "sendmail" 
uses the subroutine "pipecmd" to run /usr/bin/sendmail with command line 
parameters and a few lines of input. Pipecmd uses the open function, 
prefixing the command ("sendmail" in this case) with a pipe: open(*FD, 
"| sendmail"). Ddclient doesn't attempt to read stdout from the 
sendmail/postdrop call so presumably this is postdrop trying to read the 
pipe passed to it by sendmail?


Clearly sendmail is running in the ddclient domain (mta_sendmail_exec 
for some curious reason and not the sendmail interface) and presumably 
postdrop transitions to its own domain. This is where I think the 
problem lies and I am hoping it was my fault. At some point in trying to 
get sendmail to work I added 
"postfix_domtrans_user_mail_handler(ddclient_t)" but then found the 
answer was hiding in mta.if. This domtrans interface adds ddclient_t to 
the postfix_user_domtrans type attribute, which sesearch reveals to be 
one of the few ways of transitioning to the postfix_postdrop_t domain. 
That explains why postdrop has transitioned from sendmail (ddclient_t) 
and why it cannot access sendmail's pipe?


I am testing the policy without the domtrans call and with my fingers 
crossed.


Robert

[gentoo-hardened] SELinux Portage and Python2.7

[Robert Sharp]

Hi again,

I noticed a bunch of AVCs during my weekly update that look like a 
shortfall in the portage policy?


For example:


time->Wed Dec 14 09:50:23 2016
type=PROCTITLE msg=audit(1481709023.487:245940):
proctitle=707974686F6E322E37002F7573722F6C696236342F707974686F6E322E372F736974652D7061636B616765732F696E636C7564655F7365727665722F696E636C7564655F7365727665722E7079002D2D706F7274002F746D702F6469737463632D70756D702E31676D4479492F736F636B6574002D2D7069645F66696C65002Ftype=PATH 
msg=audit(1481709023.487:245940): item=1 
name="/dev/shm/tmpdC4SvU.include_server-27263-1" inode=4596172 dev=00:13 
mode=040700 ouid=250 ogid=250 rdev=00:00 
obj=staff_u:object_r:portage_tmpfs_t nametype=CREATE
type=PATH msg=audit(1481709023.487:245940): item=0 name="/dev/shm/" 
inode=8351 dev=00:13 mode=041777 ouid=0 ogid=0 rdev=00:00 
obj=system_u:object_r:tmpfs_t nametype=PARENT
type=CWD msg=audit(1481709023.487:245940): 
cwd="/var/tmp/portage/sys-devel/libtool-2.4.6-r2/work/libtool-2.4.6"
type=SYSCALL msg=audit(1481709023.487:245940): arch=c03e syscall=83 
success=yes exit=0 a0=c94da980 a1=1c0 a2=0 a3=1e1 items=2 ppid=27262 
pid=27263 auid=4294967295 uid=250 gid=250 euid=250 suid=250 fsuid=250 
egid=250 sgid=250 fsgid=250 tty=pts2 ses=4294967295 comm="python2.7" 
exe="/usr/bin/python2.7" subj=staff_u:sysadm_r:portage_sandbox_t key=(null)
type=AVC msg=audit(1481709023.487:245940): avc:  denied  { create } for  
pid=27263 comm="python2.7" name="tmpdC4SvU.include_server-27263-1" 
scontext=staff_u:sysadm_r:portage_sandbox_t 
tcontext=staff_u:object_r:portage_tmpfs_t tclass=dir permissive=1


And another AVC:

> type=AVC msg=audit(1481709072.864:245941): avc:  denied  { rmdir } 
for pid=27263 comm="python2.7" name="tmpdC4SvU.include_server-27263-1"
> dev="tmpfs" ino=4596172 scontext=staff_u:sysadm_r:portage_sandbox_t 
tcontext=staff_u:object_r:portage_tmpfs_t tclass=dir permissive=1


Looks like python is trying to create/remove directories within 
portage_tmpfs_t, and looking at the existing permissions:


> allow portage_sandbox_t portage_tmpfs_t:dir { search read lock 
getattr write ioctl remove_name open add_name };


suggests that it does not have the necessary permissions (e.g. create)?

Thanks

Robert Sharp

Re: [gentoo-hardened] Ddclient sending emails on a Postfix server

[Robert Sharp]

On 14/12/16 10:44, Robert Sharp wrote:

On 12/12/16 20:03, Sven Vermeulen wrote:

It's been a while that I did some Postfix work, which might be necessary to
debug this properly. The socket is owned by ddclient, is it possible that
"postdrop -r" input and/or output is redirected to a ddclient socket? From a
quick Google ddclient is shown as a Perl client, so some code scanning might
help to find out what the socket is about.


Yes, ddclient is one long perl script. I am not a perl diver myself 
but it is not difficult to track down the code. The "sub" routine 
"sendmail" uses the subroutine "pipecmd" to run /usr/bin/sendmail with 
command line parameters and a few lines of input. Pipecmd uses the 
open function, prefixing the command ("sendmail" in this case) with a 
pipe: open(*FD, "| sendmail"). Ddclient doesn't attempt to read stdout 
from the sendmail/postdrop call so presumably this is postdrop trying 
to read the pipe passed to it by sendmail?


Clearly sendmail is running in the ddclient domain (mta_sendmail_exec 
for some curious reason and not the sendmail interface) and presumably 
postdrop transitions to its own domain. This is where I think the 
problem lies and I am hoping it was my fault. At some point in trying 
to get sendmail to work I added 
"postfix_domtrans_user_mail_handler(ddclient_t)" but then found the 
answer was hiding in mta.if. This domtrans interface adds ddclient_t 
to the postfix_user_domtrans type attribute, which sesearch reveals to 
be one of the few ways of transitioning to the postfix_postdrop_t 
domain. That explains why postdrop has transitioned from sendmail 
(ddclient_t) and why it cannot access sendmail's pipe?


I am testing the policy without the domtrans call and with my fingers 
crossed.


Robert

Okay - just to apologise for rushing off down a complete rabbit hole. I 
ended up having to grant ddclient not much less the postfix admin 
rights, which rang a large alarm bell and caused me to reconsider the 
whole thing. I had started out trying to get sendmail into its own 
domain but failed. Looking harder at the various interfaces (there are 
3: postfix, sendmail and mta) I realised the answer was staring straight 
at me: "mta_send_mail". Seems to be working without any AVCs now. I will 
file a bug to request this simple addition.


Robert

[gentoo-hardened] Selinux: /bin/su and pam_selinux

[Robert Sharp]

Hi,

I have been wrestling with a problem for some time and I cannot see what 
I am doing wrong. Here is an outline:


AIM - to be able to su to root and switch off strict mode in case 
something goes wrong. I was using newrole but I kept forgetting so I am 
trying to use pam_selinux to change the role to sysadm_r. I followed the 
instructions given at 
http://blog.siphos.be/2013/04/how-logins-get-their-selinux-user-context/ 
in general, but I had to do some research to find out how to apply them 
for /bin/su.


The answer was in su.if, added to the "su_role_template" interface. I 
then spent some time figuring out how to get the roles/sysadm module to 
use my modified interface (put it in the same directory) and it 
generally seemed to work. I got a few extra AVCs but I ended up with the 
following:


optional_policy(`
domain_subj_id_change_exemption($1_su_t)
domain_role_change_exemption($1_su_t)

selinux_validate_context($1_su_t)
selinux_compute_access_vector($1_su_t)
selinux_compute_create_context($1_su_t)
selinux_compute_relabel_context($1_su_t)
selinux_compute_user_contexts($1_su_t)

seutil_read_config($1_su_t)
seutil_read_default_contexts($1_su_t)

userdom_relabelto_user_ptys($1_su_t)
userdom_dontaudit_relabelfrom_user_ptys($1_su_t)
userdom_use_user_ptys($1_su_t)
allow $1_su_t self:process setkeycreate;
allow $1_su_t $3:key manage_key_perms;
')

The PROBLEM: I still get two AVCs that I don't think I should be getting:

type=PROCTITLE msg=audit(1485020695.038:10367): 
proctitle=2F62696E2F7375002D
type=PATH msg=audit(1485020695.038:10367): item=0 name="/dev/pts/3" 
inode=6 dev=00:12 mode=020620 ouid=501 ogid=5 rdev=88:03

obj=staff_u:object_r:user_devpts_t nametype=NORMAL
type=CWD msg=audit(1485020695.038:10367): 
cwd="/home/robert/selinux/sysadm"
type=SYSCALL msg=audit(1485020695.038:10367): arch=c03e 
syscall=188 success=yes exit=0 a0=375183c820 a1=3817fb1fcaa
a2=375183bce0 a3=1c items=1 ppid=17744 pid=20374 
auid=4294967295 uid=501 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 
fsgid=0 tty=pts3
ses=4294967295 comm="su" exe="/bin/su" 
subj=staff_u:sysadm_r:sysadm_su_t key=(null)
type=AVC msg=audit(1485020695.038:10367): avc:  denied  { relabelto 
} for  pid=20374 comm="su" name="3" dev="devpts" ino=6
scontext=staff_u:sysadm_r:sysadm_su_t 
tcontext=root:object_r:user_devpts_t tclass=chr_file permissive=1


type=AVC msg=audit(1485020695.038:10368): avc:  denied  { create } 
for  pid=20374 comm="su" scontext=staff_u:sysadm_r:sysadm_su_t

tcontext=root:sysadm_r:sysadm_t tclass=key permissive=1

I double checked that I had corresponding rules to allow these:

# sesearch -s sysadm_su_t -t user_devpts_t -A
allow sysadm_su_t user_devpts_t:chr_file { read getattr write ioctl 
relabelto open append };


# sesearch -s sysadm_su_t -t sysadm_t -c key -A
allow sysadm_su_t sysadm_t:key { search setattr read create write 
link view };


So I really cannot see why I am getting these AVCs. I keep looking at 
the scripts, the rules and the AVCs to see if I have done something 
stupid, but I cannot see it. I have started making fairly arbitrary 
changes to see if I can make it go away but I am just wasting time 
really. If I cannot figure this out I suspect I will be ditching 
pam_selinux and reverting to explicitly issuing newrole. I guess with 
strict on I will quickly be reminded that I have forgotten to change 
roles anyway.


Thanks in advance,

Robert Sharp

[gentoo-hardened] SELinux cronjobs in wrong context?

[Robert Sharp]

Just when I thought I was getting near to switching on strict and all of 
a sudden my cron jobs are throwing AVCs all over.



The gist of it is all the same, for example: 
scontext=user_u:user_r:cronjob_t tcontext=system_u:object_r:crond_tmp_t. 
This is from /etc/crontab and has USER=root, so it should be run as a 
system crontab and therefore be system_cronjob_t? Here are a couple of 
specific AVCs that show this but there are many more similar or 
otherwise to do with cron jobs that worked alright until recently:



time->Mon Jan 30 13:00:01 2017
type=AVC msg=audit(1485781201.744:14756): avc:  denied  { write open } 
for  pid=26263 comm="touch" path="/var/spool/cron/lastrun/cron.hourly" 
dev="dm-0" ino=787203 scontext=user_u:user_r:cronjob_t 
tcontext=user_u:object_r:crond_tmp_t tclass=file permissive=1
type=AVC msg=audit(1485781201.744:14756): avc:  denied  { create } for  
pid=26263 comm="touch" name="cron.hourly" 
scontext=user_u:user_r:cronjob_t tcontext=user_u:object_r:crond_tmp_t 
tclass=file permissive=1
type=AVC msg=audit(1485781201.744:14756): avc:  denied  { add_name } 
for  pid=26263 comm="touch" name="cron.hourly" 
scontext=user_u:user_r:cronjob_t tcontext=system_u:object_r:crond_tmp_t 
tclass=dir permissive=1


time->Mon Jan 30 15:40:01 2017
type=PROCTITLE msg=audit(1485790801.293:14758): 
proctitle=2F62696E2F7368002F7573722F7362696E2F72756E2D63726F6E73
type=PATH msg=audit(1485790801.293:14758): item=0 
name="/var/lock/cron.hourly" inode=5592510 dev=00:11 mode=0120777 ouid=0 
ogid=0 rdev=00:00 obj=user_u:object_r:var_lock_t nametype=NORMAL

type=CWD msg=audit(1485790801.293:14758):  cwd="/"
type=SYSCALL msg=audit(1485790801.293:14758): arch=c03e syscall=6 
success=yes exit=0 a0=1626565d30 a1=3b84123bb70 a2=3b84123bb70 a3=40 
items=1 ppid=26697 pid=26698 auid=4294967295 uid=0 gid=0 euid=0 suid=0 
fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="run-crons" 
exe="/bin/bash" subj=user_u:user_r:cronjob_t key=(null)
type=AVC msg=audit(1485790801.293:14758): avc:  denied  { getattr } for  
pid=26698 comm="run-crons" path="/run/lock/cron.hourly" dev="tmpfs" 
ino=5592510 scontext=user_u:user_r:cronjob_t 
tcontext=user_u:object_r:var_lock_t tclass=lnk_file permissive=1


Also, I noticed that the files in /var/spool/cron/lastrun/ have the 
following contexts:


-rw-r--r--. 1 root root user_u:object_r:crond_tmp_t0 Jan 30 
03:10 cron.daily
-rw-r--r--. 1 root root user_u:object_r:crond_tmp_t0 Jan 30 
15:00 cron.hourly
-rw-r--r--. 1 root root system_u:object_r:system_cronjob_tmp_t 0 Jan  1 
05:30 cron.monthly
-rw-r--r--. 1 root root user_u:object_r:crond_tmp_t0 Jan 28 
04:20 cron.weekly


the cron.monthly looks like I would expect (system_cronjob_t) but the 
rest have been changed since then.


I have just checked the logs and it confirms that this behaviour started 
on 11th Jan, when I updated sec-policy/selinux-base-policy to 
2.20161023-r3. So either something got reset that I need to change, I 
haven't restarted something or there is some sort of error in the cron 
policy that is causing this?


Any ideas?

Thanks - Robert Sharp

Re: [gentoo-hardened] SELinux cronjobs in wrong context?

[Robert Sharp]

On 31/01/17 03:48, Jason Zaman wrote:

As a workaround, you can
echo "system_u:system_u:s0-s0:c0.c1023" >> /etc/selinux/mcs/seusers
you cant use semanage to add it since system_u isnt a valid user, and
you'll have to re-add that after loading modules since the file is
re-generated.
after adding that, restarting vixie-cron will make cronjobs work right
again.
Thanks. It worked a treat. I changed the same file in 
/etc/selinux/strict cos I am not operating MCS.


I will get around to fixing it real-soon-now, sorry about that!
-- Jason


Looking forward to it, but for now I will keep updating the file as and 
when. Back to where I was with su vs sudo.


Robert

[gentoo-hardened] Setools 4.1.0 emerge failure

[Robert Sharp]

Hi,
just emerged the new setools-4.1.0 and it falls over. I do not have X on 
this machine and it seems to fail when patching to remove the gui? Here 
are the details.


From emerge:

[ebuild U ~] app-admin/setools-4.1.0::gentoo [4.0.1::gentoo] USE="-X 
-debug {-test}" PYTHON_TARGETS="python2_7 python3_4 -python3_5" 0 KiB


And the error message, which comes up straight away:

>>> Unpacking source...
>>> Unpacking setools-4.1.0.tar.gz to 
/var/tmp/portage/app-admin/setools-4.1.0/work

>>> Source unpacked in /var/tmp/portage/app-admin/setools-4.1.0/work
>>> Preparing source in 
/var/tmp/portage/app-admin/setools-4.1.0/work/setools-4.1.0 ...

 * Applying setools-4.0.1-remove-gui.patch ...
1 out of 1 hunk FAILED -- saving rejects to file setup.py.rej
 [ !! ]
 * ERROR: app-admin/setools-4.1.0::gentoo failed (prepare phase):
 *   patch -p1  failed with 
/usr/portage/app-admin/setools/files/setools-4.0.1-remove-gui.patch



Quick google suggests the patch does not match the source file? Perhaps 
most people have the X flag enabled and have not met this yet? I can 
provide full details if this is not as simple as I think.


Thanks

Robert Sharp

Re: [gentoo-hardened] Setools 4.1.0 emerge failure

[Robert Sharp]

On 05/02/17 05:19, Jason Zaman wrote:

On Fri, Feb 03, 2017 at 02:54:28PM +, Robert Sharp wrote:

Hi,
just emerged the new setools-4.1.0 and it falls over. I do not have X on
this machine and it seems to fail when patching to remove the gui? Here
are the details.

I fixed it yesterday, re-emerge and it'll work now.

Thanks,
Jason

  From emerge:

[ebuild U ~] app-admin/setools-4.1.0::gentoo [4.0.1::gentoo] USE="-X
-debug {-test}" PYTHON_TARGETS="python2_7 python3_4 -python3_5" 0 KiB

And the error message, which comes up straight away:

  >>> Unpacking source...
  >>> Unpacking setools-4.1.0.tar.gz to
/var/tmp/portage/app-admin/setools-4.1.0/work
  >>> Source unpacked in /var/tmp/portage/app-admin/setools-4.1.0/work
  >>> Preparing source in
/var/tmp/portage/app-admin/setools-4.1.0/work/setools-4.1.0 ...
   * Applying setools-4.0.1-remove-gui.patch ...
1 out of 1 hunk FAILED -- saving rejects to file setup.py.rej
   [ !! ]
   * ERROR: app-admin/setools-4.1.0::gentoo failed (prepare phase):
   *   patch -p1  failed with
/usr/portage/app-admin/setools/files/setools-4.0.1-remove-gui.patch


Quick google suggests the patch does not match the source file? Perhaps
most people have the X flag enabled and have not met this yet? I can
provide full details if this is not as simple as I think.

Thanks

Robert Sharp


All working now. Thanks very much.

[gentoo-hardened] Core Policy versus selinux ebuilds

[Robert Sharp]

Is there a difference between policies that appear to be in core but 
also have their own ebuilds? For example: selinux-ddclient versus 
policy/modules/contrib/dnsmasq.* and selinux-ddclient versus 
policy/modules/contrib/ddclient. I need to change both but when I tried 
to change dnsmasq it started complaining bitterly about binding to 
random ports, which is what dnsmasq does.


Just to be absolutely clear, I expect that there is a versioning 
difference because I have pulled the latest from the git repository but 
I am using stable ebuilds, but I don't expect that this is the difference?


Thanks in advance,

Robert Sharp

Re: [gentoo-hardened] Core Policy versus selinux ebuilds

[Robert Sharp]

On 16/04/17 14:31, Jason Zaman wrote:

On Thu, Apr 13, 2017 at 12:02:24PM +0100, Robert Sharp wrote:

Is there a difference between policies that appear to be in core but
also have their own ebuilds? For example: selinux-ddclient versus
policy/modules/contrib/dnsmasq.* and selinux-ddclient versus
policy/modules/contrib/ddclient. I need to change both but when I tried
to change dnsmasq it started complaining bitterly about binding to
random ports, which is what dnsmasq does.

Not sure i follow exactly what you're asking but lemme give a quick
overview and see if it helps.


just because these things are not sec-policy/selinux-base{,-policy}
doesnt mean they all come from the /contrib/ dir inside the repo, there
are several things that are outside cthats not a requirement or
anything. eg: selinux-xserver's files are from 
services/xserver.{te,if,fc}



Hope this makes some of the magic a little clearer,
-- Jason

Thanks for your explanation. I think I understand. The git repository 
contains all of the files and the ebuilds pull in different modules? So 
if I want to change dnsmasq (so that it can talk to unbound on 553) I 
can just copy the .te/.if/.fc files from the git repository and change 
them (I have already defined the port in a cil file)?


I just tested this by making the dnsmasq module locally and comparing it 
to the /usr/share/selinux/strict one and it is the same. So now I can be 
confident that any changes I make will be the sole source of any 
problems that might follow!


Fingers crossed and many thanks again for explaining that.

Robert

[gentoo-hardened] Dnsmasq starts in wrong context after interface cycling?

[Robert Sharp]

I had a problem with Dnsmasq that led to my last post on understanding 
where policies come from. Now that I know and have had dnsmasq 
comfortably running with udp comms to unbound on port 553, I have run 
into the original problem that I thought I had caused.


I suppose I did cause it, but not in the way I imagined. I was awash 
again with AVCs from dnsmasq, but this time I took a closer look and 
realised the source context was not as expected. Instead of running in 
dnsmasq_t, it was running in resolvconf_t. I checked the binary and that 
was as expected so I restarted using run_init just to see if that was 
the problem, and it was! So now dnsmasq is running in the correct 
context, but how did it ever get to resolvconf_t? Surely if I had 
restarted it without using run_init then it would have been in sysadm_t?


One possibility is that it got into this context when my interface went 
down and up again. I had a problem last night with my Virgin fibre modem 
and I noticed that after the inevitable hardware reset, a bunch of 
services had been restarted. Besides the issue that dnsmasq is not bound 
to the interface in question, I guess I could test it quite easily, 
although I am not sure everyone else on the LAN will be too keen.


Any thoughts welcome

Robert Sharp

[gentoo-hardened] SELinux ddclient and ca-certificates

[Robert Sharp]

I have been enforcingon my SELinux box for a while without incident, 
until yesterday. Ddclient started spamming me with emails about SSL 
connect failures. I checked the audit log for AVCs and found the one 
below. The context for /etc/ssl/certs/ca-certificates is cert_t and it 
looks like the interface needed to access this type is 
"miscfiles_manage_generic_cert_files". I can test if this is the right 
approach? May take a while cos I am not sure how to force ddclient into 
attempting an update.


Thanks,
Robert

|type=AVC msg=audit(1497448811.326:13013): avc: denied { search } for 
pid=3311 comm=6464636C69656E74202D20636F6E6E name="ca-certificates" 
dev="dm-0" ino=2630168 scontext=system_u:system_r:ddclient_t 
tcontext=system_u:object_r:cert_t tclass=dir permissive=0 |||

Re: [gentoo-hardened] SELinux ddclient and ca-certificates

[Robert Sharp]

On 17/06/17 11:47, Sven Vermeulen wrote:

I generally try to make sure that it is the right domain before adding the
privilege. In the denial, the command that is being denied access is
"ca-certificates". Is that a script from ddclient, or does ddclient trigger
an (external) script and should we perhaps look at a potential domain
transition here?


Hi and thanks for the reply.

I had assumed this was the file of that name in /etc/ssl/certs but your 
comment made me check the inode and I was wrong. It is actually a 
directory "/usr/share/ca-certificates" which also has the "cert_t" 
context. There is no script by that name associated with ddclient so I 
guess ddclient is trying to (via openssl) access this directory/path?


Robert

Re: [gentoo-hardened] SELinux ddclient and ca-certificates

[Robert Sharp]

On 18/06/17 17:29, Sven Vermeulen wrote:

It's okay to use it. Manipulating the directory seems to be something I
would want to verify with the application itself first. If it is a Perl
script, then it might be easy to find out why.


Looking at the error messages and the script itself the problem occurs 
within the Perl module IO::Socket::SSL. Looks like if a call to new does 
not work then ddclient raises the message. A quick search led me to 
http://search.cpan.org/~sullr/IO-Socket-SSL-2.049/lib/IO/Socket/SSL.pod 
 
and a little way down there is a good description of "Essential 
Information About SSL/TLS". Seems to me that the module is acting as 
expected and I cannot see that ddclient is doing anything else that 
might be suspect.


So I will add the privilege and try to force ddclient to update to see 
what happens.


Best,
Robert

[gentoo-hardened] Emerge setools-4.1.1 failed

[Robert Sharp]

Had emerge of setools failure this morning:

1 out of 1 hunk FAILED -- saving rejects to file setup.py.rej
 [ !! ]
 * ERROR: app-admin/setools-4.1.1::gentoo failed (prepare phase):
 *   patch -p1  failed with 
/var/tmp/portage/app-admin/setools-4.1.1/files/setools-4.1.0-remove-gui.patch


I can provide more info later if it would be helpful?

Robert Sharp

Re: [gentoo-hardened] Re: [gentoo-dev] New item for sys-kernel/hardened-sources removal

[Robert Sharp]

On 16/08/17 11:09, Francisco Blas Izquierdo Riera (klondike) wrote:

El 16/08/17 a las 09:40, Marek Szuba escribió:

Two tiny bits of formal nitpicking from my side:
  - it's "grsecurity" (not a typo, they do use a lowercase g except when
the name appears at the beginning of a sentence), not "grsec";
  - the patches were not *distributed by* grsecurity, they *are*
grsecurity. The vendor's name is Open Source Security, Inc.

Nowadays it is, but this hasn't always been the case. You'll notice the
presence of a /dev/grsec and you'll also find grsec referenced accross
some old patches. Anyways I changed it.

The same applies to Open Source Security, Inc. the company was founded
on 2008 but grsecurity has been around for much longer. That's why I
prefer to refer to Brad Spengler and The PaX team here as they are still
the real upstream behind Open Source Security, Inc.


Would anyone like to outline a simple process to migrate from 
hardened-sources + hardened tool-chain to gentoo-sources? Presumably if 
I just drag my config file across it will cause all sorts of problems? 
Do I need to work backwards through the hardening guide, for example?


Thanks

[gentoo-hardened] Missing use flags from new profiles

[Robert Sharp]

I have moved PC's from 'hardened/linux/amd64' to 
'default/linux/amd64/17.0/hardened' and 'hardened/linux/amd64/selinux' 
to 'default/linux/amd64/17.0/hardened/selinux' and found it necessary to 
add the following use flags to avoid countless re-emerges:


MISSING="berkdb gdbm tcpd ptpax session dri urandom"

Is this a deliberate change or are they actually missing?

Thanks,

Robert Sharp

Re: [gentoo-hardened] Missing use flags from new profiles

[Robert Sharp]

On 15/12/17 14:49, Michael Orlitzky wrote:

On 12/15/2017 06:09 AM, Robert Sharp wrote:

MISSING="berkdb gdbm tcpd ptpax session dri urandom"

Is this a deliberate change or are they actually missing?


These are all intentional, but perhaps with an unintended side effect.
The default/linux profile sets,

   USE="berkdb crypt ipv6 ncurses nls pam readline ssl tcpd zlib"
   ...
   USE="${USE} cli pcre session"

Most of those flags are unnecessary, so the hardened profile disables
them (to reduce the surface area for attack):

   # Default starting set of USE flags for all default/linux profiles.
   # We unset them so we get a clean use flag profile.
   USE="${USE} -berkdb -gdbm -tcpd"
   USE="${USE} -fortran"
   USE="${USE} -cli -session"
   USE="${USE} -dri"
   USE="${USE} -modules"

What that's trying to accomplish is to undo the overzealous USE in the
default/linux profile, but unfortunately, the "-foo" flags (with the
default stacking order in portage) will override the IUSE="+foo"
defaults set in the ebuilds themselves. So, for example, dev-lang/php
sets IUSE="+cli +session", but they'll be disabled when using the
hardened profile.

USE=ptpax is something else entirely. By now, everyone should be using
the default xattr markings with PAX_MARKINGS=XT in make.conf (the new
profile does this for you). USE=ptpax was dropped by default because you
shouldn't need it any more.

At least for "modules" and "session", we will eventually drop them as
defaults so that everything works right again:

  *https://bugs.gentoo.org/635720  (modules)
  *https://bugs.gentoo.org/635742  (session)

So just to be sure I am doing the right thing, I should keep my MISSING 
use flags excluding ptpax because that way the packages that use them by 
default will be unchanged? I guess the more correct solution would be to 
add per-package use flags so that I don't add them for packages that 
have that flag but not by default? Seems like a bit more effort so I 
probably won't bother unless there is a good reason to take that approach.


Thanks, Robert

[gentoo-hardened] Hardening a Kernel post hardened-sources

[Robert Sharp]

Hi,

I still have hardened-sources running on one PC and I keep trying to 
compile a replacement gentoo-sources with as much hardening as I can, 
but I haven't found anything to help me that actually works. There are 
some guides on the Internet but most of the them are quite old (still 
grsecurity) and some of them are really old (Kernel 2.2, for example).


I found the KSPP website and built a kernel using their suggested 
"paranoid" settings. It worked for a brief moment but then I think I 
upgraded gcc to 6.4 and it just panicked during boot causing a lot of 
pain to reverse out of.


Does anyone know of a good, post GRSecurity guide to reasonable security 
for the kernel? In the absence of anything else I will have to go back 
to the KSPP list and start removing stuff until I can get a stable kernel.


Thanks in advance,

Robert Sharp

Re: [gentoo-hardened] Hardening a Kernel post hardened-sources

[Robert Sharp]

I requested a quote from GRsecurity and they told me that although they 
are looking at providing a package for personal customers they don't 
have one at the moment. They recommended minipli as the next best thing...


What about the grsecurity-source overlay?

On 29/03/18 11:47, Guillaume Ceccarelli wrote:

Hi all,

I’ve been a grsecurity customer for a little over two years now, and 
my use of it is as a small business, on Gentoo server installations. 
While I can’t disclose the amount of money I’m paying publicly because 
every deal is customized, I would encourage you to get in touch using 
the contact form on grsecurity.net <http://grsecurity.net/> and ask 
for a quote if you haven’t already.


You might just end up with an arrangement you can afford, and grsec is 
still certainly worth having today. Not only for the feature set, but 
also for the constant looking over the mainline Linux kernel code, 
including fixing and backporting more fixes than the regular kernel 
stable releases, and for knowledge / emails giving context to 
important kernel vulnerabilities when they occur.



Best,

– Guillaume Ceccarelli

On 28 Mar 2018, at 20:22, R0b0t1 <mailto:r03...@gmail.com>> wrote:


On Wed, Mar 28, 2018 at 12:40 PM, Alex Efros <mailto:power...@powerman.name>> wrote:

Hi!

On Wed, Mar 28, 2018 at 06:06:00PM +0100, Robert Sharp wrote:
Does anyone know of a good, post GRSecurity guide to reasonable 
security

for the kernel? In the absence of anything else I will have to go back
to the KSPP list and start removing stuff until I can get a stable 
kernel.


I'm using https://github.com/minipli/linux-unofficial_grsec, but it 
lacks

Spectre and Meltdown mitigation at the moment (see issues). Still, I
believe it's the best we can have now (better is probably paid 
GrSec, but
AFAIK it's impossible or too costly to buy it for home or small 
business).




Previous contributors have access to the code, but it doesn't seem
like there is any way to go that route anymore.

Re: [gentoo-hardened] Hardening a Kernel post hardened-sources

[Robert Sharp]

On 30/03/18 17:55, R0b0t1 wrote:

Is there any way for you to try again while presenting yourself as a
business? In some jurisdictions saying you are a business is all it
takes to start a sole proprietorship. Otherwise, just pretend you are
affiliated with a (legally fictional) business.


Its more than possible: I have a business, email addresses, registered 
at Company's House the lot. I guess there is nothing to lose but I think 
it likely the price is more than I could justify. I will have another go 
over the holiday weekend.


I am leaning towards having another go at the KSPP approach and being a 
little more cautious about what I include. I don't like the idea of 
being stuck on an older kernel version waiting for someone to find time 
to catch up and I can probably apply the same approach to all my PC's 
and not just the outward facing ones.


Best

Robert