The secmark "one user" policy

[Paul Moore]

On Tue, Jun 27, 2017 at 6:51 AM, José Bollo <jobol at nonadev.net> wrote:
> On Mon, 26 Jun 2017 08:10:44 -0700
> Casey Schaufler <casey at schaufler-ca.com> wrote:
>
>> On 6/26/2017 12:54 AM, José Bollo wrote:
>> > On Sun, 25 Jun 2017 11:05:24 -0700
>> > Casey Schaufler <casey at schaufler-ca.com> wrote:
>> >
>> >> On 6/25/2017 2:41 AM, James Morris wrote:
>> >>> On Fri, 23 Jun 2017, Casey Schaufler wrote:
>> >>>
>> >>>> On 6/22/2017 8:12 PM, James Morris wrote:
>> >>>>> On Thu, 22 Jun 2017, Casey Schaufler wrote:
>> >>>>>
>> >>>>>> The combination of SELinux, Smack, AppArmor and/or TOMOYO is
>> >>>>>> not the goal so much as the test case. MAC was the coolest
>> >>>>>> possible technology in 1990. We've implemented it. I don't see
>> >>>>>> anyone doing a new MAC implementation. I *do* see security
>> >>>>>> modules that implement other security models in the pipeline.
>> >>>>>> Some of these need to maintain state, which means using
>> >>>>>> security blobs in the LSM architecture. Some of these models
>> >>>>>> will want to use secmarks to implement socket based
>> >>>>>> controls.
>> >>>>> Where are these LSMs and where are the discussions about their
>> >>>>> LSM API needs?
>> >>>> LandLock, CaitSith, LoadPin (now in), Checmate, HardChroot,
>> >>>> PTAGS, SimpleFlow, SafeName, WhiteEgret, shebang, and S.A.R.A.
>> >>>> have all been discussed on the LSM list in the past two
>> >>>> years.
>> >>> Which of these need to use secmarks to implement socket
>> >>> controls?
>> >> PTAGS doesn't, but will need to do so to be complete.
>> > Hello Casey,
>> >
>> > The very sleepy PTAGS is suddently awaken (at least one ear :^).
>> >
>> > In my mind, PTAGS is dealing with processes. When packets are
>> > filtered, the only revelent info is the emitter process. At the
>> > moment, I don't see valuable situation where mediation isn't
>> > explicit thus faking origin isn't needed.
>> >
>> > So I would really like to understand your vision here. What do I
>> > miss?
>>
>> My thought is that getting the tags of the process on the other
>> end of a network connection seems like a valuable facility.
>
> I can see 3 objections: (1) secmark isn't really interesting for
> transmitting hierachical strings; (2) maintaining 2 or more remotes in
> a coherent state implies more than implicit assumptions; (3) never
> trust the network.

A point of clarification: the secmark labels are not communicated
across the network, they are assigned to packets based on the local
netfilter configuration.

A simple example with SELinux/secmark:

 # iptables -t mangle -A INPUT --src 192.168.0.16 \
   -p tcp --dport 22 -j SECMARK \
   --selctx system_u:object_r:foo_ssh_packet_t:s0

-- 
paul moore
www.paul-moore.com
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html