In this patch we're sending an ICMPv6 message to a peer to
immediately inform it that making a connection is not possible.
In case of TCP connections, without this change, the peer
will be waiting until a connection timeout is exceeded.
Signed-off-by: Piotr Sawicki <p.sawicki2(a)partner.samsung.com>
Changes in v2:
- Add missing Signed-off-by field
Changes in v3:
- Fix formatting issues caused by improper email client configuration
security/smack/smack_lsm.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/security/smack/smack_lsm.c b/security/smack/smack_lsm.c
index c2282ac..efa81bc 100644
@@ -28,6 +28,7 @@
@@ -4010,6 +4011,9 @@ static int smack_socket_sock_rcv_skb(struct sock *sk, struct sk_buff *skb)
rc = smk_ipv6_port_check(sk, &sadd, SMK_RECEIVING);
#endif /* SMACK_IPV6_PORT_LABELING */
+ if (rc != 0)
+ icmpv6_send(skb, ICMPV6_DEST_UNREACH,
+ ICMPV6_ADM_PROHIBITED, 0);
#endif /* CONFIG_IPV6 */
On 1/30/2019 4:47 AM, Eric W. Biederman wrote:
> ebiederm(a)xmission.com (Eric W. Biederman) writes:
>> ebiederm(a)xmission.com (Eric W. Biederman) writes:
>>> Casey Schaufler <casey(a)schaufler-ca.com> writes:
>>>> Are you taking the LSM specific mount options into account?
>>> In the design yes, and I allow setting them. It appears in the code
>>> to retrieve the mount options I forgot to call security_sb_show_options.
>>> For finding the super block that you are going to mount the LSM mount
>>> options are not relevant. Even nfs will not want to set those early as
>>> they do not help determine the nfs super block. So the only place where
>>> there is anything interesting in my api is in reading back the security
>>> options so they can be compared to the options the mounter is setting.
>>> I will add the missing call to security_sb_show_options which is enough
>>> to fix selinux. Unfortunately smack does not currently implement
>>> .sb_show_options. Not implementing smack_sb_show_options means
>>> /proc/mounts fails to match /etc/mtab which is a bug and it is likely
>>> a real workd bug for the people who use smack and don't want to depend
>>> on /etc/mtab, or are transitioning away from it.
>>> Casey do you want to implement smack_sb_show_options or should I put it
>>> on my todo list?
>> Oh. I should add that I am always parsing the LSM mount options out so
>> that there is not a chance of the individual filesystems implementing
>> comflicting options even when there are no LSMs active. Without that I
>> am afraid we run the risk of having LSM mount otions in conflict with
>> ordinary filesystems options at some point and by the time we discover
>> it it would start introducing filesystem regressions.
>> That does help with stack though as there is no fundamental reason only
>> one LSM could process mount options.
> Sigh. I just realized that there is a smack variant of the bug I am
> working to fix.
> smack on remount does not fail if you change the smack mount options.
> It just silently ignores the smack mount options. Which is exactly the
> same poor interaction with userspace that has surprised user space
> and caused CVEs.
> How much do you think the smack users will care if you start verifying
> that if smack options are present in remount that they are unchanged
> from mount?
I've added the smack-discuss list to the conversation.
> I suspect the smack userbase is small enough, and the corner case is
> crazy enough we can fix this poor communication by smack. Otherwise it
> looks like there needs to be a new security hook so old and new remounts
> can be distinguished by the LSMs, and smack can be fixed in the new
I fear that it may be worse than that. It's not enough to distinguish
a mount from a remount. On remount you need an LSM specific way to
compare mount options. Smack may decide that it's OK to remount a
filesystem with more restrictive smackfshat values, for example. Or,
it may allow smackfsroot=Pop for one and smackfstransmute=Pop on
the other. I'm not sure about the 2nd case, but you should get the idea.