On Tue, Jul 23, 2013 at 09:54:23AM -0400, Christopher J. PeBenito wrote:
> On 7/23/2013 8:22 AM, Sven Vermeulen wrote:
> > I would like to be able to assign attributes to types in a conditional
> > statement. Right now, this isn't allowed, and I don't know if it is feasible
>
> Definitely a question for main SELinux list.
Ah ok, sorry about that.
> > to look for a solution to this or not. Is this a real design constraint that
> > will be hard to work around, or is this doable?
>
> It would require kernel changes. Someone else can be more specific about the challenges for implementing it, but the one complication I can think of off the top of my head is that attributes are expanded in the base module during compile time.
The base only? Because attributes are declared in (non-base) modules as
well. Also, if they are expanded during policy (re)build, I was hoping we
could do some implementation without impacting SELinux at the kernel.
> > Alternatives that I see are:
>
> What I had always hoped would alleviate this was the tunable implementation. I was hoping it would have the same statement constraints as an optional, but instead of being controlled by dependence, it would be controlled by a Boolean or a Boolean expression (separate ones from the current booleans). I think that almost all of the conditional policy we have right now should be tunable instead, since they are changes you make once (e.g. NFS home dirs), so it makes more sense as a link-time configuration option (aka tunable). Then you wouldn't be wasting kernel memory on options you'll never toggle again. That would eliminate the implementation issues of having conditional type attributes or conditional role* statements.
>
> However, the current implementation leverages the current conditionals; thus, it has the same constraints on usage. Right now I think the best bet is to get CIL up and running, because it should have appropriate infrastructure for tunables as I described above.
Forgive me for being clueless here, but from what I gather you're saying
that the current build system (refpolicy) is using "tunable_policy" as a
term, but underlyingly using booleans ("bool"), and when you say "tunable"
above it is more like the ifdef(...) stuff? Aka, not really a
SELinux-specific term but a build-time definition?
I didn't consider the ifdef(...) possibilities, perhaps with some tweaking
on the refpolicy build system we can easily introduce some approach.
I don't know if CIL is the best bet; I've heard a lot from it, but never got
around to playing with it - are you planning on having a CIL-refpolicy
somewhere that we can base on? I wouldn't mind trying out CIL integration in
Gentoo, if not just in an overlay...
> > - making the assignations part of separate, small SELinux modules that users can unload/load
>
> I think Fedora does this a little. I am resistant to upstreaming it since it really breaks encapsulation.
I'm not fond of it either, even though my reason is pure due to aesthetics:
if I run "semodule -l", I want to see the isolated modules, not a possible
set of them.
So rather
~# semodule -l | grep mysql
mysql 1.13.5
and not
~# semodule -l | grep mysql
mysql 1.13.5
permissive_mysqld_t 1.13.5
which, btw, is already in place in current upstream ("semanage permissive"
support). I'm not against the "semanage permissive" feature itself, I think
it is a wonderful feature that many users forget - but aesthetics-wise, I
find it not that beautiful. Oh well, coloribus and something...
> > - using interfaces that assign the permissions to the given domain, and use
> > this interface against the attribute. This will probably result in two
> > interfaces, foo_domain() to assign the attribute (for non-tunable usage)
> > and foo_domain_privileges() to assign the rights (for tunable usage) -
> > naming convention notwithstanding here.
>
> We have a little of this, but I'd like to eliminate it because it breaks abstraction. The hope is that the implementation of the interface shouldn't affect how a caller uses it.
True, but the design method of using attributes and assigning privileges to
the attributes breaks the ability of modules to conditionally enable the
privileges.
Personally, I would like to put much more "tweakable" permissions in the
policies (similar to the Gentoo USE flag methodology). Conditionals (the
current "tunable_policy()" macros) are a good match for this, except for the
typeattribute support. So that leaves me with either designing modules that
don't use attributes (which isn't optimal either, because attributes are a
nice way of bundling types) or finding another way.
> > - decouple the requirement from the policy and let administrators do this
> >
> > The last approach means that the policy doesn't include the definitions
> > anymore, instead providing a method (in the SELinux userspace utilities or
> > distribution-specific) to assign attributes.
>
> I'm a little surprised that you'd suggest that, as it makes more work for distro maintainers. I'd be reluctant to do this, since it makes stock refpolicy less useful as a starting point for a system policy.
If this would go all the way, yes, but that was never my intention. It was
just one of the possibilities that I saw for implementing the feature.
The hint about ifdef support (if I read it correctly ;-) was one I didn't
see at first - I'll think about that one as well, as it opens some options I
didn't capture at first.
Wkr,
Sven Vermeulen
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@xxxxxxxxxxxxx with
the words "unsubscribe selinux" without quotes as the message.
