Hello Paul! The message subject used in the Reference Policy mailing list is: "Update the lvm module" and it's one of the most recent posting. I haven't tried yet reproducing the problem outside of the system bootup. I believe it happens when cryptsetup uses the user-space interface to the kernel Crypto API. Do you have any idea on the reason why the class is being marked as "socket" instead of "unix_stream_socket" (for sequential packet socket)? Best regards, Guido On the 20th august 2016 20:44:45 CEST, Paul Moore <pmoore@xxxxxxxxxx> wrote: >On Sat, Aug 20, 2016 at 1:39 PM, Guido Trentalancia ><guido@xxxxxxxxxxxxxxxx> wrote: >> Hello Paul, >> >> thanks for getting back on this. >> >> The patch follows a recent discussion with Christopher PeBenito on >the Reference Policy mailing list. > >Which patch/thread (what was the subject line)? I have seen a lot of >patches and discussion between you and Chris lately (thanks for your >contributions!) but I haven't followed them very closely. > >> Christopher suggested to modify the actual code. >> >> I suppose it provides a better insight during code analysis on the >type of socket connections being made and a more fine-grained control >of permissions being granted or denied to the policy designer. > >The only value I can see to this change would be if we needed to >differentiate between AF_UNIX stream and seqpacket connections, and to >be honest I don't see the difference being that important. As I said >before, we need to understand what you are trying to solve and how it >is only possible with this change. The unspecified problem you are >seeing below wont be resolved by this patch (as you already >mentioned). > >> For some reason however, I have seen code using the SOCK_SEQPACKET >type and executed immediately after policy load (possibly from >initramfs, before switchroot) showing up in the log files as using an >unspecified socket type. I have explained already to Christopher that >this patch won't change such behavior... > >Yes, that should be unrelated to this change. Are you able to >reproduce the above problem reliably? _______________________________________________ Selinux mailing list Selinux@xxxxxxxxxxxxx To unsubscribe, send email to Selinux-leave@xxxxxxxxxxxxx. To get help, send an email containing "help" to Selinux-request@xxxxxxxxxxxxx.
