-
Notifications
You must be signed in to change notification settings - Fork 185
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
cf-agent --bootstrap fails on Debian systems. #1050
Conversation
…uts is a symlink to /etc/cfengine3. The bootstrap creates 'failsafe.cf' in /etc/cfengine3, but cf-agent complains that this sys.workdir/inputs is a symlink. Both must fail/complain or we accept symbolic link to a directory. This patch enable the last option. It will determine if the destination is a symlink to a directory and ```copy_from``` attribute ```type_check : false``` is set. If both options are true the copy will be honoured.
I think this is right, IMO there's no reason to refuse the inputs directory if it's a symlink. |
cf-agent --bootstrap fails on Debian systems.
Agreed. And merged! :-) |
Thanks a lot!! |
I want to comment on this. Just find out that test:
We have to add: |
Indeed. This test also fails: ./10_files/templating/mustache_abuse.cf. |
@kacfengine The test you mentioned has nothing to do with the patch. The patch is only for the |
You're probably right. I haven't checked the details myself. I'll look into it. |
The mustache test failure was from an unrelated commit, fixed in #1052 in any case. |
…_cp``` * type_check : true
…010_test Due to pull request cfengine#1050
@basvandervlies @vohi @kacfengine can this fix be backported to 3.5.x? (also asked in Webhuis/Cfengine-debian#41) |
Hm, what would be a reason for cf-agent refusing an inputs directory that's a symlink, and what's the implication of permitting this? Would like to understand this before we accept this change and back port it to a drop-in replacement maintenance release. |
On 13/11/13 15:59, Volker Hilsheimer wrote:
Two reasons:
I strongly advise to never allow symbolic links of directories, and also M Founder and CTO at CFEngine |
People do run CFEngine as none root in production. I've seen application teams do this. So being able to deploy and bootstrap as a non root user is a good feature. So rather than root, file should not be group or world writable. I do agree that symlinks are risky. If they are allowed then there must be check on the destination, as described above. Similarly there could be a check that directories are not network file systems. |
On 13 nov. 2013, at 15:59, Volker Hilsheimer notifications@github.com wrote:
There are 2 scenarios:
SURFsara has a new telephone number: +31 20 800 1300. Bas van der Vlies |
I think, however, that the fundamental issue here may be different. The problem is that the client doesn't need to know that Another less intrusive approach is for the server to expose the |
After direct discussion with @markburgess and looking at the possible issues from symlinks in the masterfiles dir path, I see there are a few possible problems we haven't considered. There are race conditions that can be exploited, for instance. So please consider the first paragraph above retracted and (in case it wasn't clear) note that anything I state is my humble opinion and not "speaking ex cathedra for CFEngine." The second and third paragraphs, regarding how the server can present an abstract location to the clients, are for a "logically consistent" solution implemented on the server side. Something like rsync modules, where you can say @basvandervlies what do you think about, on the server side, making a special Debian policy (executed by the default cf-agent policy on the hub) to synchronize |
@tzz just a quick response. It is all about client side for me. I never used the boostrap before:
This will fail on the client. cf-agent will create '''/etc/cfengine/failsafe.cf''' and does not care that sys.workdir is a symlink to '''/etc/cfengine'''. After this '''cf-agent -f failsafe.cf''' will run and this fails and complains about it. It is only for cf-agent client configuration files to my knowledge and as nothing to do with the cf-serverd. we have '''move_obstruction''' option for '''body copy_from'''. This will remove the offending file if it is not a directory. Maybe the generated failsafe.cf should include this option then it does not fail. Then it is still strange that the bootstrap process can create a file in a symlinked directory. I just tested this with my old cfengine server 3.3.2-1. I made the following change:
I can just copy the cfengine configuration files. maybe something is patched between versions to prevent this. I have to test it with a new cf-serverd version. ''/etc/cfengine/masterfiles''' is not the right direction. You also do not place '''masterfiles''' in ''''sys.workdir/inputs'''. This was not a quick response ;-) |
Can you elaborate on how? This is already in master, so if there are security implications we should be aware of them. |
Google symlink security issues. Generally, when something is excluded explicitly in the code or done in a none-obvious way, its a sign there is a reason. Worth asking up front. Symlinks are hard to validate and can enable local root exploits when trusted by root. Kristian Amlie notifications@github.com wrote:
|
Ok just did a test with the 3.5.X branch and cf-serverd. My first question is how can i debug a child connection nothing seems to be logged when we encounter a problem in child thread: cf-serverd -dF (only initial connection). Now for cf-serverd. symlinks are alllowed for I like to emphasis that the this pull request is for '''cf-agent''' and not ''cf-serverd''' |
@basvandervlies (I can't believe there's no way to enter a backtick from an iPhone o_O) |
Googling symlink security issues does not turn up any useful results for me. It's all either old security holes that have been fixed, or misunderstandings about the security implications of symlinks. If anyone is aware of any security issues, they need to post the details here, how the feature can be exploited. There is no need for discretion, since this version hasn't been released yet. There are many ways to shoot yourself in the foot with CFEngine, I don't see how symlinks are any different. An administrator can of course make an insecure symlink to a user owned directory, but then he has noone to blame but himself. |
Quoting Mark's respective paragraph from the email discussion:
I recommend we revert that change in master until everybody has understood the reason for current behaviour. |
@markburgess @vohi Please revert the change. It is a bad one. I completely agree. Just did a scenario:
'''' It wil just copy the data to '''/root/bas''' and that is a symlink attack. Thanks for noticing this!!! The "old" version reports:
this is the example files: body copy_from purge_copy(from) body depth_search select_recurse(d,exclude_list) body action update_immediate |
@markburgess, @vohi, @basvandervlies: Thanks for explaining. There is indeed a security hole there, since this function also deals with untrusted directories. I will revert it tomorrow. |
+1.. Great discussion indeed! Thanks @basvandervlies for verifying it |
I learned a lot ;-). I will report the issue that '''bootstrap.c''' must report that '''sys.workdir/inputs''' is not directory and maybe remove it and recreate it. Now for cf-serverd. symlinks are alllowed for masterfiles directory if there are on the same filesystem. Is this ok? |
@basvandervlies: Me too! I have reverted the commit in #1087. |
@basvandervlies: I think the key element is whether the symlink itself is trusted. If it resides in /var/cfengine, and is owned by root, it should be safe to assume that it is a secure link. The same is not true for symlinks that could reside in user directories. |
@kacfengine that is correct. We have to check if the owner of the link is the same as the directory were it points to. |
@kacfengine i just added a check if the owners matches and if not display a message. |
Yes, I think a fix like that is what we need. I'll be discussing this issue a bit in-house first, to try to minimize the chance of ending up in this situation again. |
just reopen the call so it is not off the radar. we can always close it if it is not accepted |
Because sys.workdir/inputs is a symlink to /etc/cfengine3. The bootstrap process creates
failsafe.cf
in /etc/cfengine3, but cf-agent complains that this sys.workdir/inputs is a symlink and aborts the bootstrap process. Both must fail/complain or both must accept the symbolic link to the directory as destination.This patch enable the last option. It will determine if the destination is a symlink to a directory and
copy_from
attributetype_check : false
is set. If both options are true the copy will be honored.