SELinux+IPTables+Non SELINUX Aware Network Daemon

SELinux+IPTables+Non SELINUX Aware Network Daemon

[GProcunier]

[-- Attachment #1.1.1: Type: text/plain, Size: 1683 bytes --]

Greetings,

I was recently reading this article about leveraging iptables with SELinux 
: 

https://www.linux.com/learn/tutorials/421152-using-selinux-and-iptables-together

I was wondering if a similar union could allow for the following situation 
to be accomplished:

I have a Red Hat Enterprise Linux 6.1 server sharing several storage LUNs 
as iSCSI targets via the native iSCSI target implementation in that 
distribution.  For technical reasons several of the LUNs must be exported 
without CHAP authentication however I was wondering if I could leverage 
iptables secmark in conjunction with SELinux to accomplish the following:

1) Client IP connects to the iSCSI target service.  Connection is tracked 
and secmark'd.
2) Client IP discovers available LUNs on the iSCSI server
3) Client IP logs into a LUN which has an source address access rule 
preventing access.
4) When the iSCSI target service tries to access the LUN to which the 
Client IP has no access, IPtables severs the connection via TCP reset / 
reject. 

As far as I can tell "tgtd" (the iSCSI target daemon) neither supports IP 
acl's or is SELinux aware, however I was hoping there might be a way to 
create an association between connecting ip / process ID on the server and 
file/block device access such that I could use IPtables to terminate the 
unauthorized connection.

If anyone has any thoughts on if this would be possible in one way or 
another I would love to hear about it.

Cheers,

--

Greg Procunier
UNIX Administrator III - Enterprise Servers and Storage
1 Robert Speck Parkway, Suite 400, Mississauga, Ontario L4Z 4E7
Office: 416-673-3320 
Mobile: 647-895-2977
Email: gprocunier@symcor.com

[-- Attachment #1.1.2: Type: text/html, Size: 2680 bytes --]

[-- Attachment #1.2: Type: image/jpeg, Size: 3258 bytes --]

[-- Attachment #2: Type: text/plain, Size: 1036 bytes --]



CONFIDENTIALITY WARNING 
This communication, including any attachments, is for the exclusive use of addressee and may contain proprietary and/or confidential information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this communication and destroy all copies.

AVERTISSEMENT RELATIF À LA CONFIDENTIALITÉ 
Ce message, ainsi que les pièces qui y sont jointes, est destiné à l’usage exclusif de la personne à laquelle il s’adresse et peut contenir de l’information personnelle ou confidentielle. Si le lecteur de ce message n’en est pas le destinataire, nous l’avisons par la présente que toute diffusion, distribution, reproduction ou utilisation de son contenu est strictement interdite. Veuillez avertir sur-le-champ l’expéditeur par retour de courrier électronique et supprimez ce message ainsi que toutes les pièces jointes.

Re: SELinux+IPTables+Non SELINUX Aware Network Daemon

[Eric Paris]

[-- Attachment #1: Type: text/plain, Size: 4847 bytes --]

Nobody jumped in so I'll answer you.  The answer is that no, you cannot do
this with what you have today as you describe it.  SELinux can be used to
control what IP addresses tgtd is allowed to talk to.  It can also control
what block devices tgtd is allowed to talk to.  But SELinux does not have a
way to tie an IP address to a block device.  That information cannot be
magically transferred through the tgtd daemon.  Lets say we have

Hosts: 1, 2, and 3
Block devices: hda, hdb, and hdc

If I understand your situation correctly a similar example might be summed
up as follows.  You want Host 1 to ONLY be allowed to use block device hda.
 You want host 2 to ONLY be allowed to use block device hdb.  You do not
want tgtd to talk to host3.  You do not want anything to use hdc.

We can write iptables labeling rules and policy which only grants tgtd the
ability to talk to host1 and host2.  We can write policy rules which would
only give tgtd access to hda and hdb.  What we cannot do is control if host1
tries to mount and use hdb.  We don't have a way to get that information
through the tgtd program.  Think of tgtd as a black box.  SELinux can
control what comes in and out of the box, but once inside it can't do
anything about it.

              ----------
host 1 <---> |          | <---> hda
host 2 <---> |   TGTD   | <---> hdb
host 3 <---X |          | X---> hdc
              ----------

We can control the that boundary between host 3 and tgtd or between tgtd and
hdc.  But if we let both hda and hdb talk to tgtd and we let both host1 and
host2 talk to tgtd we cannot control if tgtd allows host1 to get information
from hdb.  We can't control what happens INSIDE the black box.  Now, if you
can come up with a way to run 2 copies of tgtd, so you have 2 black boxes,
that could be made to work.  Otherwise you are going to have to change tgtd
to implement the controls you seek....

Make sense?

2011/8/22 <GProcunier@symcor.com>

> Greetings,
>
> I was recently reading this article about leveraging iptables with SELinux
> :
>
>
> https://www.linux.com/learn/tutorials/421152-using-selinux-and-iptables-together
>
> I was wondering if a similar union could allow for the following situation
> to be accomplished:
>
> I have a Red Hat Enterprise Linux 6.1 server sharing several storage LUNs
> as iSCSI targets via the native iSCSI target implementation in that
> distribution.  For technical reasons several of the LUNs must be exported
> without CHAP authentication however I was wondering if I could leverage
> iptables secmark in conjunction with SELinux to accomplish the following:
>
> 1) Client IP connects to the iSCSI target service.  Connection is tracked
> and secmark'd.
> 2) Client IP discovers available LUNs on the iSCSI server
> 3) Client IP logs into a LUN which has an source address access rule
> preventing access.
> 4) When the iSCSI target service tries to access the LUN to which the
> Client IP has no access, IPtables severs the connection via TCP reset /
> reject.
>
> As far as I can tell "tgtd" (the iSCSI target daemon) neither supports IP
> acl's or is SELinux aware, however I was hoping there might be a way to
> create an association between connecting ip / process ID on the server and
> file/block device access such that I could use IPtables to terminate the
> unauthorized connection.
>
> If anyone has any thoughts on if this would be possible in one way or
> another I would love to hear about it.
>
> Cheers,
>
> --
>
> *Greg Procunier*
> *UNIX Administrator III - Enterprise Servers and Storage*
> 1 Robert Speck Parkway, Suite 400, Mississauga, Ontario L4Z 4E7
> Office: 416-673-3320
> Mobile: 647-895-2977
> Email: gprocunier@symcor.com
>
>
> CONFIDENTIALITY WARNING
> This communication, including any attachments, is for the exclusive use of
> addressee and may contain proprietary and/or confidential information. If
> you are not the intended recipient, any use, copying, disclosure,
> dissemination or distribution is strictly prohibited. If you are not the
> intended recipient, please notify the sender immediately by return e-mail,
> delete this communication and destroy all copies.
>
> AVERTISSEMENT RELATIF À LA CONFIDENTIALITÉ
> Ce message, ainsi que les pièces qui y sont jointes, est destiné à l’usage
> exclusif de la personne à laquelle il s’adresse et peut contenir de
> l’information personnelle ou confidentielle. Si le lecteur de ce message
> n’en est pas le destinataire, nous l’avisons par la présente que toute
> diffusion, distribution, reproduction ou utilisation de son contenu est
> strictement interdite. Veuillez avertir sur-le-champ l’expéditeur par retour
> de courrier électronique et supprimez ce message ainsi que toutes les pièces
> jointes.
>
>

[-- Attachment #2: Type: text/html, Size: 6472 bytes --]

Re: SELinux+IPTables+Non SELINUX Aware Network Daemon

[GProcunier]

[-- Attachment #1.1.1: Type: text/plain, Size: 4149 bytes --]

Thank you that was very helpful.

--

Greg Procunier
UNIX Administrator III - Enterprise Servers and Storage
1 Robert Speck Parkway, Suite 400, Mississauga, Ontario L4Z 4E7
Office: 416-673-3320 
Mobile: 647-895-2977
Email: gprocunier@symcor.com

owner-selinux@tycho.nsa.gov wrote on 08/23/2011 03:35:28 PM:

> From: Eric Paris <eparis@parisplace.org>
> To: GProcunier@symcor.com
> Cc: selinux@tycho.nsa.gov
> Date: 08/23/2011 03:41 PM
> Subject: Re: SELinux+IPTables+Non SELINUX Aware Network Daemon
> Sent by: owner-selinux@tycho.nsa.gov
> 
> Nobody jumped in so I'll answer you.  The answer is that no, you 
> cannot do this with what you have today as you describe it.  SELinux
> can be used to control what IP addresses tgtd is allowed to talk to.
>  It can also control what block devices tgtd is allowed to talk to. 
>  But SELinux does not have a way to tie an IP address to a block 
> device.  That information cannot be magically transferred through 
> the tgtd daemon.  Lets say we have
> 
> Hosts: 1, 2, and 3
> Block devices: hda, hdb, and hdc
> 
> If I understand your situation correctly a similar example might be 
> summed up as follows.  You want Host 1 to ONLY be allowed to use 
> block device hda.  You want host 2 to ONLY be allowed to use block 
> device hdb.  You do not want tgtd to talk to host3.  You do not want
> anything to use hdc.
> 
> We can write iptables labeling rules and policy which only grants 
> tgtd the ability to talk to host1 and host2.  We can write policy 
> rules which would only give tgtd access to hda and hdb.  What we 
> cannot do is control if host1 tries to mount and use hdb.  We don't 
> have a way to get that information through the tgtd program.  Think 
> of tgtd as a black box.  SELinux can control what comes in and out 
> of the box, but once inside it can't do anything about it.
> 
>               ----------
> host 1 <---> |          | <---> hda
> host 2 <---> |   TGTD   | <---> hdb
> host 3 <---X |          | X---> hdc
>               ----------
> 
> We can control the that boundary between host 3 and tgtd or between 
> tgtd and hdc.  But if we let both hda and hdb talk to tgtd and we 
> let both host1 and host2 talk to tgtd we cannot control if tgtd 
> allows host1 to get information from hdb.  We can't control what 
> happens INSIDE the black box.  Now, if you can come up with a way to
> run 2 copies of tgtd, so you have 2 black boxes, that could be made 
> to work.  Otherwise you are going to have to change tgtd to 
> implement the controls you seek....
> 
> Make sense?
> 
> 2011/8/22 <GProcunier@symcor.com>
> Greetings, 
> 
> I was recently reading this article about leveraging iptables with 
SELinux : 
> 
> https://www.linux.com/learn/tutorials/421152-using-selinux-and-
> iptables-together 
> 
> I was wondering if a similar union could allow for the following 
> situation to be accomplished: 
> 
> I have a Red Hat Enterprise Linux 6.1 server sharing several storage
> LUNs as iSCSI targets via the native iSCSI target implementation in 
> that distribution.  For technical reasons several of the LUNs must 
> be exported without CHAP authentication however I was wondering if I
> could leverage iptables secmark in conjunction with SELinux to 
> accomplish the following: 
> 
> 1) Client IP connects to the iSCSI target service.  Connection is 
> tracked and secmark'd. 
> 2) Client IP discovers available LUNs on the iSCSI server 
> 3) Client IP logs into a LUN which has an source address access rule
> preventing access. 
> 4) When the iSCSI target service tries to access the LUN to which 
> the Client IP has no access, IPtables severs the connection via TCP 
> reset / reject. 
> 
> As far as I can tell "tgtd" (the iSCSI target daemon) neither 
> supports IP acl's or is SELinux aware, however I was hoping there 
> might be a way to create an association between connecting ip / 
> process ID on the server and file/block device access such that I 
> could use IPtables to terminate the unauthorized connection. 
> 
> If anyone has any thoughts on if this would be possible in one way 
> or another I would love to hear about it. 
> 
> Cheers, 
> 


[-- Attachment #1.1.2: Type: text/html, Size: 6183 bytes --]

[-- Attachment #1.2: Type: image/jpeg, Size: 3258 bytes --]

[-- Attachment #2: Type: text/plain, Size: 1036 bytes --]



CONFIDENTIALITY WARNING 
This communication, including any attachments, is for the exclusive use of addressee and may contain proprietary and/or confidential information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this communication and destroy all copies.

AVERTISSEMENT RELATIF À LA CONFIDENTIALITÉ 
Ce message, ainsi que les pièces qui y sont jointes, est destiné à l’usage exclusif de la personne à laquelle il s’adresse et peut contenir de l’information personnelle ou confidentielle. Si le lecteur de ce message n’en est pas le destinataire, nous l’avisons par la présente que toute diffusion, distribution, reproduction ou utilisation de son contenu est strictement interdite. Veuillez avertir sur-le-champ l’expéditeur par retour de courrier électronique et supprimez ce message ainsi que toutes les pièces jointes.