-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Please Review, and ack.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk8HLfkACgkQrlYvE4MpobPcMwCeLEt3tTKzR4l9SK3OoR7pcdvX
yFAAn2ychju1KNrywdbUJG+x1tNnWKv9
=SSPD
-----END PGP SIGNATURE-----
-------------- next part --------------
A non-text attachment was scrubbed...
Name: cfengine.patch
Type: text/x-patch
Size: 5880 bytes
Desc: not available
Url : http://oss.tresys.com/pipermail/refpolicy/attachments/20120106/95772d3f/attachment-0001.bin
On Fri, Jan 06, 2012 at 12:23:05PM -0500, Daniel J Walsh wrote:
> Please Review, and ack.
[...]
Are you certain this one works? As far as I know, cfengine has a similar
functionality to puppet, and the puppet policy has many more privileges. I
also don't see any interfaces that can be used by administrators to interact
with the cfengine components.
The cfengine reference manual also contains quite a few components that I
don't see mentioned. Although some of them probably run pretty well in the
caller domain (and as long as they're labeled bin_t that's okay) but I'm not
sure that they don't need particular privileges in /var/cfengine(/.*)?
I'll see if I can stage a small VM to play with this a bit - just looks a
bit strange to me.
Wkr,
Sven Vermeulen
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 01/09/2012 03:26 PM, Sven Vermeulen wrote:
> On Fri, Jan 06, 2012 at 12:23:05PM -0500, Daniel J Walsh wrote:
>> Please Review, and ack.
> [...]
>
> Are you certain this one works? As far as I know, cfengine has a
> similar functionality to puppet, and the puppet policy has many
> more privileges. I also don't see any interfaces that can be used
> by administrators to interact with the cfengine components.
>
> The cfengine reference manual also contains quite a few components
> that I don't see mentioned. Although some of them probably run
> pretty well in the caller domain (and as long as they're labeled
> bin_t that's okay) but I'm not sure that they don't need particular
> privileges in /var/cfengine(/.*)?
>
> I'll see if I can stage a small VM to play with this a bit - just
> looks a bit strange to me.
>
> Wkr, Sven Vermeulen
> _______________________________________________ refpolicy mailing
> list refpolicy at oss.tresys.com
> http://oss.tresys.com/mailman/listinfo/refpolicy
No I am not sure that this one works. I know it is in our policy and
looks pretty comprehensive, not sure who wrote it. I would figure
most of this needs to be unconfined like the puppet policy. But It
seems like a good start to the policy.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk8LTwYACgkQrlYvE4MpobPK+wCgltKO4InNq6KnKU9HJB+siDHN
gOUAnjJ/wIuHyfN9JXgIqnbsPxIExZup
=alg6
-----END PGP SIGNATURE-----
On Mon, Jan 09, 2012 at 03:33:10PM -0500, Daniel J Walsh wrote:
> > Are you certain this one works? As far as I know, cfengine has a
> > similar functionality to puppet, and the puppet policy has many
> > more privileges. I also don't see any interfaces that can be used
> > by administrators to interact with the cfengine components.
> >
> > The cfengine reference manual also contains quite a few components
> > that I don't see mentioned. Although some of them probably run
> > pretty well in the caller domain (and as long as they're labeled
> > bin_t that's okay) but I'm not sure that they don't need particular
> > privileges in /var/cfengine(/.*)?
> >
> > I'll see if I can stage a small VM to play with this a bit - just
> > looks a bit strange to me.
>
> No I am not sure that this one works. I know it is in our policy and
> looks pretty comprehensive, not sure who wrote it. I would figure
> most of this needs to be unconfined like the puppet policy. But It
> seems like a good start to the policy.
There's no "unconfined_domain" call in there, which you might want to add
then.
For me, I don't mind putting in modules that might not be fully finished yet
as long as they already have shown proper thought about domain naming (so
that future reshuffles aren't necessary) and the interfaces, as far as they
are already defined, are in good shape.
The rest is imo local to the policy and as such can be changed in future
revisions anyhow.
Style-wise, the module looks okay, so for me it's okay.
Wkr,
Sven Vermeulen