Prev: omap_hsmmc: Add erase capability
Next: [announce] gujin gpl bootloader version 2.8.2
From: Casey Schaufler on 18 Jun 2010 22:30
Eric W. Biederman wrote:
> Theodore Tso <tytso(a)MIT.EDU> writes:
>
>
>> i think we really need to have stacked LSM's,

!

>> because there is a large set
>> of people who will never use SELinux. Every few years, I take another
>> look at SELinux, my head explodes with the (IMHO unneeded complexity),
>> and I go away again...
>>
>> Yet I would really like a number of features such as this ptrace scope idea ---
>> which I think is a useful feature, and it may be that stacking is the only
>> way we can resolve this debate. The SELinux people will never believe that
>> their system is too complicated, and I don't like using things that are impossible
>> for me to understand or configure, and that doesn't seem likely to change anytime
>> in the near future.
>>
>> I mean, even IPSEC RFC's are easier for me to understand, and that's saying
>> a lot...
>>
>
>
> If anyone is going to work on this let me make a concrete suggestion.
> Let's aim at not stacked lsm's but chained lsm's, and put the chaining
> logic in the lsm core.
>

It's 35 years since my data structures course. What's the important
difference between the two?

> The core difficulty appears to be how do you multiplex the security pointers
> on various objects out there.
>

That and making sure that the hooks that maintain state get called
even if the decision to deny access has already been made by someone
else.

> My wishlist has this working so that I can logically have a local security
> policy in a container, restricted by the global policy but with additional
> restrictions.
>
> Eric
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo(a)vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
>
>

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Eric W. Biederman on 18 Jun 2010 23:00
Casey Schaufler <casey(a)schaufler-ca.com> writes:

> Eric W. Biederman wrote:
>> Theodore Tso <tytso(a)MIT.EDU> writes:
>>
>>
>>> i think we really need to have stacked LSM's,
>
> !
>
>>> because there is a large set
>>> of people who will never use SELinux. Every few years, I take another
>>> look at SELinux, my head explodes with the (IMHO unneeded complexity),
>>> and I go away again...
>>>
>>> Yet I would really like a number of features such as this ptrace scope idea ---
>>> which I think is a useful feature, and it may be that stacking is the only
>>> way we can resolve this debate. The SELinux people will never believe that
>>> their system is too complicated, and I don't like using things that are impossible
>>> for me to understand or configure, and that doesn't seem likely to change anytime
>>> in the near future.
>>>
>>> I mean, even IPSEC RFC's are easier for me to understand, and that's saying
>>> a lot...
>>>
>>
>>
>> If anyone is going to work on this let me make a concrete suggestion.
>> Let's aim at not stacked lsm's but chained lsm's, and put the chaining
>> logic in the lsm core.
>>
>
> It's 35 years since my data structures course. What's the important
> difference between the two?

Who takes responsibility for making it work, and where you implement
it. If it is in the LSM it is a feature all LSMs automatically
support it. If it is stacked it is an LSM by LSM feature.

Basically implementing chaining is just a walk over a list of
security_operations and calling the appropriate method on each one.

Stacked LSMs at least as I saw it in selinux was the implementation of
each security operation doing calling internally calling the secondary
lsm's security options. Which seems to me to be more code, and harder
to maintain, and a setup that encourages politics.

>> The core difficulty appears to be how do you multiplex the security pointers
>> on various objects out there.
>>
>
> That and making sure that the hooks that maintain state get called
> even if the decision to deny access has already been made by someone
> else.

Yep.

Except for dealing with state maintenance it is absolutely trivial
to implement chained LSMs.

Eric
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Frank Ch. Eigler on 18 Jun 2010 23:30
Kees Cook <kees.cook(a)canonical.com> writes:

> [...] At present, I'm aware of global PTRACE control being possible
> in SELinux, AppArmor, grsecurity, and as a patch in Ubuntu's kernel.
> I don't know about TOMOYO or Smack, but configuring the default
> scope of PTRACE in at least 4 different ways so far (or not being
> able to change it at all) just seems crazy. [...]

For the curious, below is a demonstration an interactive systemtap
script that can implement this sort of local policy, independently of
the other security APIs.

http://sourceware.org/systemtap/examples/keyword-index.html#SECURITY

just a user sammy sysadmin
=========== ==============

8232% echo $$
8232

root# noptrace.stp -x 8232 &

8232% do-stuff &
[1] 8888
root# cat /proc/systemtap/stap_*/blocked
8232 /bin/bash
8888 /usr/local/bin/do-stuff

8232% strace ls
strace: ptrace(PTRACE_TRACEME, ...): No such process
8232% gdb do-stuff 8888
Attaching to program: /usr/local/bin/do-stuff, process 8888
ptrace: No such process.

root# echo 8232 > /proc/systemtap/stap_*/unblock

8232% strace ls
[...working again...]


- FChE
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: James Morris on 20 Jun 2010 21:00
On Fri, 18 Jun 2010, Theodore Tso wrote:

> Yet I would really like a number of features such as this ptrace scope idea ---
> which I think is a useful feature, and it may be that stacking is the only
> way we can resolve this debate.

We've already reached a consensus that these things should be put into a
separate LSM so we can evaluate the possible need for some form of
stacking or a security library API.

Note that people using SELinux or AppArmor already have the ability to
restrict ptrace, and they would thus not need to stack this function if it
were in a separate LSM.

Do you have a use-case where stacking would be useful here?



- James
--
James Morris
<jmorris(a)namei.org>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Valdis.Kletnieks on 20 Jun 2010 22:20
On Mon, 21 Jun 2010 10:52:11 +1000, James Morris said:

> Note that people using SELinux or AppArmor already have the ability to
> restrict ptrace, and they would thus not need to stack this function if it
> were in a separate LSM.

That's assuming they can figure out how to write and integrate the required
policy changes. Looking inside selinux-policy-3.8.3-4.fc14.src.rpm from Fedora
Rawhide: (Holy cow, there's a .git tree in that tarball - no wonder it's 20M in
size).

% cd serefpolicy-3.8.3/policy/modules; wc -l */* | grep total
135967 total

135kloc of policy that probably nobody in your shop really understands. At
that point, writing something that stacks starts sounding really enticing.


First  |  Prev  | 
Pages: 1 2 3 4 5 6 7
Prev: omap_hsmmc: Add erase capability
Next: [announce] gujin gpl bootloader version 2.8.2