--
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@xxxxxxxxxx
owner-selinux@xxxxxxxxxxxxx wrote on 08/23/2011 03:35:28 PM:
> From: Eric Paris <eparis@xxxxxxxxxxxxxx>
> To: GProcunier@xxxxxxxxxx
> Cc: selinux@xxxxxxxxxxxxx
> Date: 08/23/2011 03:41 PM
> Subject: Re: SELinux+IPTables+Non SELINUX Aware Network Daemon
> Sent by: owner-selinux@xxxxxxxxxxxxx
>
> 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@xxxxxxxxxx>
> 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,
>
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.
