Hi all,
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
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?
Alternatives that I see are:
- making the assignations part of separate, small SELinux modules that users can unload/load
- 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.
- 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.
For instance (mock-up):
~# semanage attribute -a -t mailserver_domain portage_t
This would then create (or maintain) a small module that does the necessary
declarations, like "typeattribute portage_t mailserver_domain".
What is your opinion on this? Weird request?
Wkr,
Sven Vermeulen
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 07/23/2013 08:22 AM, Sven Vermeulen wrote:
> Hi all,
>
> 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 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?
>
> Alternatives that I see are: - making the assignations part of separate,
> small SELinux modules that users can unload/load - 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. - 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.
>
> For instance (mock-up):
>
> ~# semanage attribute -a -t mailserver_domain portage_t
>
> This would then create (or maintain) a small module that does the
> necessary declarations, like "typeattribute portage_t mailserver_domain".
>
> What is your opinion on this? Weird request?
>
> Wkr, Sven Vermeulen
>
> _______________________________________________ refpolicy mailing list
> refpolicy at oss.tresys.com http://oss.tresys.com/mailman/listinfo/refpolicy
>
I think it is fairly difficult, and I like the idea of enabling and disabling
modules to handle this. In Fedora we currently disable the unconfined module
which removes the domain_unconfined_type attribute from lots of domains.
We have done similar things with other domains. (Network stuff).
We probably should have a naming convention for this to make it easy to find
and potentially display them in a gui.
MODULE_tunable.pp Or something like that, then we could enable or disable the
tunable to take away certain attributes.
NFSHOMEDIR_tunable.pp
CIFSHOMEDIR_tunable.pp
FUSEFSHOMEDIR_tunable.pp
For example.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.13 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iEYEARECAAYFAlHugWoACgkQrlYvE4MpobNW3QCg50PxfJPCXRx9PK1hGnctV7Hg
NdIAoLTI3dfju8zOZ62aH3kPRZrArLP5
=m8MN
-----END PGP SIGNATURE-----
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.
> 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.
> 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.
> - 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.
> - 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.
> - 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.
--
Chris PeBenito
Tresys Technology, LLC
http://www.tresys.com | oss.tresys.com
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