file editing and SELinux

[Tina Friedrich]

Hello list,

we're increasingly running into trouble because file edits (as in,
edit_line bundles) appear to change the security context of files.

I'm trying to implement a mechanism whereby 'restorecon' is called on a
file whenever it's been edited.

Got the impression that we're not the only ones doing this / trying to
do this; how have people implemented this? My first thought was to
simply add a 'restorecon $(edit.filename)' command to all edit_line
bundles we use - however, edit_line bundles can't contain commands. As
they also can't call methods, making it a method to be called on
$(edit.filename) also won't work :).

Suppose I could set an 'if_repaired' class for it, but don't want to
have to call an extra method on every file we edit, naturally. There
isn't an array with all files it edited, or something equally helpful,
is there?

Hints/suggestions?

Tina

--
Tina Friedrich, Computer Systems Administrator, Diamond Light Source Ltd
Diamond House, Harwell Science and Innovation Campus - 01235 77 8442

--
This e-mail and any attachments may contain confidential, copyright and or privileged material, and are for the use of the intended addressee only. If you are not the intended addressee or an authorised recipient of the addressee please notify us of receipt by returning the e-mail and do not use, copy, retain, distribute or disclose the information in or attached to the e-mail.
Any opinions expressed within this e-mail are those of the individual and not necessarily of Diamond Light Source Ltd.
Diamond Light Source Ltd. cannot guarantee that this e-mail or any attachments are free from viruses and we cannot accept liability for any damage which you may sustain as a result of software viruses which may be transmitted in or with the message.
Diamond Light Source Limited (company no. 4375679). Registered in England and Wales with its registered office at Diamond House, Harwell Science and Innovation Campus, Didcot, Oxfordshire, OX11 0DE, United Kingdom

[Juris Krumins]

Hi Tina.
I completely agree, than inability to handle extended file attr. (specifically SElinux attr.) is a pain in CFEngine when you work in SELinux enabled env.
So we've taken following aproach:
1. When we repair/make changes to file we save absolute file name in temporary file and set global class
2. At the end, if global class was set, end temporary file contain entries we process them using restorecon

Of course you if you have non-default file security context you need to maintain local configuration file (file_contexts.local) for all of them.
Probably not the most elegant way to maintain things, but this is something.
By the way, the time between file changes and method, which repair context can cause application to be unstable and/or even crash.

[Tina Friedrich]

Hi Juris,

I thought about using a mechanism like this; my first stab at it was
trying to keep them in memory (in an array), but had no luck getting
this to work yet. So I might have to resort to temp file, as well.

I agree it would really be good if this could be fixed. SElinux is quite
common these days, or not? A newly re-designed management system that
you (still) have to work around because it (still) breaks your system
due to disregarding a valid and valuable security mechanism really makes
me scratch my head a bit :) Actually, cfengine 2 handled this better,
come to think of it; at least it only messed up security context on
creating a file, not on each edit.

Tina

> --
> You received this message because you are subscribed to the Google
> Groups "help-cfengine" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to help-cfengin...@googlegroups.com.
> To post to this group, send email to help-c...@googlegroups.com.
> Visit this group at http://groups.google.com/group/help-cfengine?hl=en.
> For more options, visit https://groups.google.com/groups/opt_out.

[Shane McEwan]

On 23/05/13 10:46, Tina Friedrich wrote:
> I agree it would really be good if this could be fixed. SElinux is quite
> common these days, or not? A newly re-designed management system that
> you (still) have to work around because it (still) breaks your system
> due to disregarding a valid and valuable security mechanism really makes
> me scratch my head a bit :) Actually, cfengine 2 handled this better,
> come to think of it; at least it only messed up security context on
> creating a file, not on each edit.

I'm not sure how CFEngine edits files but I assume, because the security
context is getting messed up, that it's moving the existing file and
creating a new file in its place. We can talk about solutions that don't
mess up the security context in the first place or ensures the context
of the original file is re-applied to the new file but the correct
solution is to be able to promise the security context of the file just
the same way as you promise the permissions. Then it won't matter if the
edit messes the context because CFEngine will ensure it is fixed. As a
bonus, if the context is changed by other means (either legitimately or
not) CFEngine will fix that as well.

I'm not sure if CFEngine has SELinux support (I haven't seen anything
but I haven't looked!) but it would be a very useful addition. And at
the same time add support for AppArmor as well. I imagine it would be
part of the "perms" body.

Shane.

[Tina Friedrich]

Correct; it gets 'messed up' because it creates a new file, and then
copies it into place.

I'm not sure that promising the security context is the correct way - it
would be good to be able to, yes.

However, in this case - for editing of configuration files etc - I don't
really know/care what the security context is/was - I just want to be
able to rely on my config management *not changing it* (especially not
without warning me about it). Surely not too much to ask? :)

Tina

[Juris Krumins]

I would say, that it'll be great if CFEngine will insure new file (just in case file gets copied/moved/modified) will have the same ext. attr. as original one in case original one already exists, plus the ability to define ext. attr. using perm/<you_name_it> attribute in file promise.
So when you specifically define ext. attr. on a file those will enforced, otherwise ext. attr should be preserved ether from original file or from the parent directory (like it happens in SELinux).

[Tina Friedrich]

I believe it actually comes from SElinux fcontext 'database' (what type
a file needs to be, that is) - that's the place that defines what type
something should have, isn't it? (/etc/cups, for example, is a different
type from /etc/cups/client.conf - so it's not inherited from directory
like permissions would be).

Shame one can't call a method or command within an edit_line bundle -
that would enable a much nicer workaround, at least. Am considering
replacing all our line edits with a method call to an agent bundle that
would handle both the edit and the security context setting...

Tina

> --
> You received this message because you are subscribed to the Google
> Groups "help-cfengine" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to help-cfengin...@googlegroups.com.
> To post to this group, send email to help-c...@googlegroups.com.
> Visit this group at http://groups.google.com/group/help-cfengine?hl=en.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>

[Tina Friedrich]

Have found a solution to this problem that seems to work for us - it's
not perfect, but neat enough.

Basically, I added a transformer doing 'sbin/restorecon
$(this.promiser)" to the "files:" stanza of every file we edit/copy.
Means it runs them every time, of course (not only when edited -
unfortunately, transformers don't know about if_repaired); but it does
at least makes sure the files that cfengine touches have the correct
security context.

It would still be nice if one didn't have to do this at all, and I still
think that a management software silently changing attributes of files
should be considered a bug.

Tina

[Gregory Matthews]

On 23/05/13 17:16, Tina Friedrich wrote:
> It would still be nice if one didn't have to do this at all, and I still
> think that a management software silently changing attributes of files
> should be considered a bug.

https://cfengine.com/dev/issues/2545

>
> Tina


--
Greg Matthews 01235 778658
Scientific Computing Group Leader
Diamond Light Source Ltd. OXON UK

[Neil Watson]

On Thu, May 23, 2013 at 05:16:17PM +0100, Tina Friedrich wrote:
>Basically, I added a transformer doing 'sbin/restorecon
>$(this.promiser)" to the "files:" stanza of every file we edit/copy.
>Means it runs them every time, of course (not only when edited -
>unfortunately, transformers don't know about if_repaired); but it
>does at least makes sure the files that cfengine touches have the
>correct security context.

What if your first files promise set an if_repaired class, then a second
files promise, limited by the repaired class of the first, used the
transformer?


--
Neil Watson
Linux/UNIX Consultant
http://watson-wilson.ca

[Aleksey Tsalolikhin]

On Thu, May 23, 2013 at 9:30 AM, Gregory Matthews <greg.m...@diamond.ac.uk> wrote:

On 23/05/13 17:16, Tina Friedrich wrote:

It would still be nice if one didn't have to do this at all, and I still
think that a management software silently changing attributes of files
should be considered a bug.

https://cfengine.com/dev/issues/2545

Thank you, Greg.  I agree, Tina.  May I encourage you to update 2545 with this comment, Tina?

I would like to see 2545 closed in 3.5; I've started discouraging people from using CFEngine for editing vital system files until 2545 is fixed.

Yours,

-at

--

CFEngine Training:
Irvine, California, October 14 - 17.  http://cf3irvine.eventbrite.com/

[Volker Hilsheimer]

On Thursday, May 23, 2013 9:48:23 PM UTC+2, atsaloli.tech wrote:

On Thu, May 23, 2013 at 9:30 AM, Gregory Matthews <greg.m...@diamond.ac.uk> wrote:

On 23/05/13 17:16, Tina Friedrich wrote:

It would still be nice if one didn't have to do this at all, and I still
think that a management software silently changing attributes of files
should be considered a bug.

https://cfengine.com/dev/issues/2545

Thank you, Greg.  I agree, Tina.  May I encourage you to update 2545 with this comment, Tina?

I would like to see 2545 closed in 3.5; I've started discouraging people from using CFEngine for editing vital system files until 2545 is fixed.

Since that's a separate issue from the problem that files disappear during edit operations, I've moved this to a new ticket:

https://cfengine.com/dev/issues/2728 

Fixing this will require build system changes etc, so we won't make 2728 block the fix for 2545.

Volker

[Tina Friedrich]

Thanks Volker.

Yes, I thought it was rather a separate (though related) issue. Beat me
to opening a bug for it!

Tina

On 24/05/13 11:00, Volker Hilsheimer wrote:
>
>
> On Thursday, May 23, 2013 9:48:23 PM UTC+2, atsaloli.tech wrote:
>
>
>
>
> On Thu, May 23, 2013 at 9:30 AM, Gregory Matthews
> <greg.m...@diamond.ac.uk <javascript:>> wrote:
>
> On 23/05/13 17:16, Tina Friedrich wrote:
>
> It would still be nice if one didn't have to do this at all,
> and I still
> think that a management software silently changing
> attributes of files
> should be considered a bug.
>
>

> https://cfengine.com/dev/__issues/2545

> <https://cfengine.com/dev/issues/2545>
>
>
> Thank you, Greg. I agree, Tina. May I encourage you to update 2545
> with this comment, Tina?
>
> I would like to see 2545 closed in 3.5; I've started discouraging
> people from using CFEngine for editing vital system files until 2545
> is fixed.
>
>
> Since that's a separate issue from the problem that files disappear
> during edit operations, I've moved this to a new ticket:
>
> https://cfengine.com/dev/issues/2728
>
> Fixing this will require build system changes etc, so we won't make 2728
> block the fix for 2545.
>
> Volker
>

> --
> You received this message because you are subscribed to the Google
> Groups "help-cfengine" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to help-cfengin...@googlegroups.com.
> To post to this group, send email to help-c...@googlegroups.com.
> Visit this group at http://groups.google.com/group/help-cfengine?hl=en.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>


--
Tina Friedrich, Computer Systems Administrator, Diamond Light Source Ltd

Diamond House, Harwell Science and Innovation Campus - 01235 77 8442

[Tina Friedrich]

I thought about that, yes. I couldn't really figure how to 'transfer'
the file name into the second files promise. Yes, I could simply always
have two file promises for the same file. But I'd still need a specific
class for every file, as well, wouldn't I (as classes are global - i.e.
simply setting a 'need_to_run_restorecon' would still trigger it on all
of the files). So that approach seemed to come with a lot more potential
for clashes, confusion (and typos)...

Tina

[Neil Watson]

On Fri, May 24, 2013 at 11:31:13AM +0100, Tina Friedrich wrote:
>I thought about that, yes. I couldn't really figure how to 'transfer'
>the file name into the second files promise. Yes, I could simply
>always have two file promises for the same file. But I'd still need a
>specific class for every file, as well, wouldn't I (as classes are
>global - i.e. simply setting a 'need_to_run_restorecon' would still
>trigger it on all of the files). So that approach seemed to come with
>a lot more potential for clashes, confusion (and typos)...

Use list and iteration. Lot's of examples here:
https://github.com/evolvethinking/evolve_cfengine_freelib/blob/master/masterfiles/libraries/evolve_freelib.cf

files:
"${svc[${s}][2]}" -> { "${svc[${s}][9]}" }
comment => "Promise contents of configurationn file from template",
handle => "efl_service_files_config_template",
create => "true",
edit_defaults => empty,
ifvarclass => canonify( "${svc[${s}][3]}_is_a_template" ),
edit_template => "${efl_c.cache}/${svc[${s}][2]}",
classes => if_repaired( "efl_service_command_${svc[${s}][8]}" ); ##<<<<<<<

commands:
"${svc[${s}][8]}" -> { "${svc[${s}][9]}" }
comment => "Restart service is required.",
handle => "efl_service_commands_restart",
contain => in_shell_and_silent,
ifvarclass => canonify( "efl_service_command_${svc[${s}][8]}" ); ##<<<<<<<