*ALL* school IT departments don't view things the same way. So the bottom line to the question might be ... asking them what they see as security issues ... and be specific - techie lingo. Then come back to this thread and post the edited/obscured response you get from them.
Will say this ... think the feature will present some problem solving for the true server admin ... not the Moodle Admin but the true operating system server admin. And much of that persons perspective might actually be tied to what Operating System the Moodle is run from.
You might pass along to them this URL if you haven't already done so:
https://docs.moodle.org/31/en/Global_search
This requires an extension to Apache and PHP not normally found on AMP stacks ... a solr server.
You can find references to the above at the URL given.
Having said all that ... take a look at your current Moodle. Are there paths set for things like du, aspell, etc.?
If on Windows, more than likely those are not used.
Generally, it's not a good idea to have code call for the execution of something operating system that normally would be used only from command line. But, if one looks at du, spell, dot, whatever one can see that those particular 'executables' on a Linux system really do help the code in that the code will use the scripts ... thus making whatever routine in code that would use 'du' for example, faster. (du BTW, is disk usage).
At one point in time, there were some system specific executables that came with the Moodle package (still is in moodlecode/filter/tex/ ... mimetex.linux mimetex.exe ... matter of fact the mimetex.linux I discovered one day was a 32 bit version ... which sometimes complained on a 64 bit box.
Anyway ... an not a security expert but there are some cases where using something operating system isn't (to me) all that much of a show stopper. The du command just calculates disk space/usage. I guess, someone could find a way to execute the specific php scripts contained in Moodle that execute du in such a fashion that it becomes something like a self-denial of service, but Moodle code is such am not all certain it could be done via browser - or a remote / non-authenticated php or curl or wget call.
Today, in my mind, everything/anything web based is a risk. Will say that Moodle coders are very security minded (at least core coders). Maybe not so much so for 3rd party developers ... that, BTW, is a problem for/with any popular open sourced software ... like WordPress or Joomla's, etc.. That's where the local server admin comes in - keeping those up to date is no longer a 'will get around to it' item on their list of things to do ... it should be given a high priority.
So ... probably shouldn't ask this ... and not suggesting that you query your IT staff that support you ... but what of the overall security of servers those folks admin? Example: is your current Moodle code the highest/most secure in the series that you are running now?
If not, why not?
That might make some stammer/stutter a little .... seems to me if one touts security reasons for nixing something then a security type should not only talk the talk, but walk the walk! Are there gray areas when it comes to security? (food for thought, not response).
So sometimes things are really a risk assessment ... does the + for using out weight the 'potential' security issues? If one knows of potential security issues is there something that can be run to check on a regular basis (like error logs of apache/php/moodle).
Sorry for the length of this response but don't think there is an easy answer to the question. Wish there was!
Others, am sure will have different takes, and could very well respond refuting whatever I've said here. Maybe my response will draw a true certified security expert (whatever tha means) into responding! ;)
'spirit of sharing', Ken
I asked our IT department for more information of the security risks they are concerned about. This was their response:
We do not recommend that it be installed on the Moodle servers at this time. This recommendation is based on several security and maintenance issues associated with the installation. Currently, we limit the number of packages that are installed on the Moodle servers to make the attack surface as small as possible. Installing unoconv/Libreoffice would add approximately 15% more packages to the system and would greatly increase the attack surface. The package manager currently contains version 0.6 of unoconv while Moodle requires version 0.7, so unoconv would have to be compiled from the source (e.g. unknown third-party developer), greatly complicating maintenance and applying bug fixes. All other software on the servers except Moodle itself comes directly from the package manager.
In addition, Libreoffice is a desktop application that would reside on a server exposed to the Internet. Even, if a new server is set up to host Libreoffice to allow remote access, unoconv will still need to be installed on the web servers bringing the potential security issues. There would also be an increase in the complexity of the Moodle architecture due to adding another server for the conversion process.
If unoconv in the package manager was updated to version 0.7 that is supported by Moodle there would still be issues with the install. The current unoconv 0.6 package has dependences on Libreoffice so it would need to be a non-standard install to install just unoconv without Libreoffice which could potentially cause issues during maintenance.
Finally, some applications such as Maple, Matlab and other specialized academic applications would need to be printed to PDF for submission due to lack of support in unoconv and Libreoffice. As a workaround faculty can require students to submit all files in PDF format.
See you are a core developer and a plugin developer by the icons. Hmmm ...
First, am kinda surprised that the developer of this added feature to core 3.1 of Moodle
hasn't at least popped in here. Guess leaving it up to me ... a community member ... to follow
up on conversation. Seems to be somewhat an un-written rule that the first responder take it
as far as they can. While I have been a user of Moodle (and a contributor - but not official plugins, etc.), have never claimed I knew it all ... no one does, IMHO. Am finding it rather difficult sometimes to justify decisions made by Moodle, Moodle HQ, Moodle Association so am not going to try. Heck, it's free/community software ... knowing that means one takes the good with the bad and lives with it.
So to clips from the response and further 'mind games' ...
"we limit the number of packages that are installed on the Moodle servers to make the attack surface as small as possible"
Wise to keep things minimal ... use only what one will use. Have any plugins to Moodle
that are hidden or can you see any of that?
Since responder has said 'package manager' that indicates it's Linux ... what distro?
What are your server's version of PHP, MySQL, Apache right now?
You can see via Server PHP Info. No need to disclose.
Just compare versions you see your Moodle is running under right now
with CVE vulnerabilities links below:
http://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=PHP
http://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=MySQL
http://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=Apache
If this person is talking the talk, he/she should walk the walk. By that I mean your server
DOESN'T need any updates to any of the apps required to run Moodle. Matter of fact, open source works like this ... an issue discovered ... a fix/patch is made available as soon as it's available via "package manager' (unlike 30 day 'Patch Tuesday' or or Apples whenever!). As a developer you know that!!!
Installing unoconv/Libreoffice would add approximately 15% more packages to the system and would greatly increase the attack surface.
15%?!!??? Where does this person get that percentage?
That a full install of LibreOffice? With dictionaries for all languages? or just what one needs ... like they say they do already?
http://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=LibreOffice
The most recent:
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-0795
LibreOffice before 5.0.5 allows remote attackers to cause a denial of service (memory corruption) or possibly have unspecified other impact via a crafted LwpTocSuperLayout record in a LotusWordPro (lwp) document.
Notice a few things .... 1 the version of LibreOffice affected in the above is
*below* version 5.0.5
What version is available from the 'package manager' on your system?
And the vulnerability says ... LotusWordPro (lwp) document ... do y'all use
LotusWordPro?
I see by the CVE link above it's been confirmed on Ubuntu ...
http://www.ubuntu.com/usn/USN-2899-1/
"It was discovered that LibreOffice incorrectly handled LWP document files.
If a user were tricked into opening a specially crafted LWP document, a
remote attacker could cause LibreOffice to crash, and possibly execute
arbitrary code."
Note: "if a user were tricked into opening a specifically created LWP docuemnt" ... in this case documents have been uploaded (not opened by a user ON the server, etc., etc.). But note the problem can be corrected by running libreoffoce-core ... higher version.
The package manager currently contains version 0.6 of unoconv while Moodle requires version 0.7, so unoconv would have to be compiled from the source (e.g. unknown third-party developer)
Guess he/she referring to Dag Wieers ... well known in the open source community, me thinks.
Holy Crap on a Cracker!
Sounds like package manager to which he/she has referred is not keeping up.
So compiling (while a little more work) would actually be better rather than worse. Compiling, BTW, used to be the ONLY way one could build an AMP stack server. I still compile some things rather than use a 'package manager'.
IF the responder is really serious about security, then that's what should be done with Apache, MySQL, PHP, etc.. ... compile them all (but the responder doesn't do that ... hmmmmm).
"Even, if a new server is set up to host Libreoffice to allow remote access, unoconv will still need to be installed on the web servers bringing the potential security issues."
Yeah! Sooooo .... hmmmmm ... ask your server admin to investigate mimetex in Moodle. Never heard of a proxy? Never heard of a backend box with a private IP that talks to the public facing web server? Heck, folks do that for DB servers and for NFS servers all the time.
I think the real bottom line here is this ... just as in his/her response:
"Finally, some applications such as Maple, Matlab and other specialized academic applications would need to be printed to PDF for submission due to lack of support in unoconv and Libreoffice. As a workaround faculty can require students to submit all files in PDF format."
Does your entity have Maple and Matlab? Are those services?
http://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=Maple
http://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=Matlab
Just for fun ... the last link has only one:
LIBSNDFILE.DLL, as used by AOL Nullsoft Winamp 5.33 and possibly other products, allows remote attackers to execute arbitrary code via a crafted .MAT (MATLAB sound) file that contains a value that is used as an offset, which triggers memory corruption.
.DLL ... windows only.
It's all about risk assessment now-a-days ... everything has an element of risk. Ask yourself, does this added feature trump the risk? If that "risk" is breached, then server admin can always disable/un-install it.
My 2 cents ... anyone from Moodle Core care to comment ... add to ... etc.??
'spirit of sharing', Ken
Unoconv is not something that is usually installed on a webserver and therefore it is not simple as e.g. a php extension. Server admins should take time to think about the impact of installing unoconv and decide when and how they should make it available to Moodle.
Responses to the recommendations from your IT department:
1. Yes openoffice is a large set of packages (hundreds of MB) which you may or may not want to install on your webserver depending on your security policy etc.
2. The latest debian packages for unoconv 0.7 can be installed directly on LTS ubuntu versions (for example) with no issues because the script depends only on python3 and recommends libreoffice but doesn't specify a version. The same is probably true for other distributions - but I haven't looked into it.
3. Uploading all submissions as PDF is a valid workaround and unoconv is entirely optional. Unoconv is a nice feature if you can have it but should be definitely be considered optional.
One way to potentially avoid installing all of openoffice on the webserver:
Install it on a non-public server that is accessible to the webserver and replace the unoconv script with a shell script that will execute the command on the other server. The simplest way to set this up I can imagine is to use public/private ssh key authentication and a bash script like the following to forward the command. Note that the moodledata folder will need to be shared to both servers and the account on the unoconv server will need read/write/execute permission to the files in that folder.
#!/bin/bash
# Script to forward unoconv commands to another server without relying on the unoconv package locally.
ssh ACCOUNTNAMEONUNOCONVSERVER@UNOCONVSERVERHOSTNAME unoconv "$@"
Save that to a text file named /usr/local/bin/unoconv and change the permissions to 755 and it should work.
If you do this I would still recommend running a unoconv listener on the unoconv server to prevent errors with concurrent file conversions as described in the Moodle unoconv installation docs.
I can understand a server admin initially baulking at connecting what seems like desktop software to an internet accessible service - but LibreOffice has been designed to be used this way - and it provides exactly the feature set we require.
Should we have written our own office document reader ? Definitely not - we would only have supported a tiny subset of formats, probably introduced our own security holes and bugs and would have diverted massive resources to something that is not our core mission. We chose to use a well supported widely distributed open source office suite to do this because it is well supported, widely used and open source. There may be bugs/security issues with open office - if you find any please report them and they will be fixed.
LibreOffice is used in environments such as the Dutch ministry of defence (http://www.cmswire.com/information-management/a-look-at-how-libreoffice-liberates-content/)
I like your response, Damyon. I have been interested in this discussion about unoconv because it seems like an interesting, and maybe necessary piece in order to grade a variety of file submissions in the assignments activity. For example, most of my assignment submittals are Excel files.
I am not a server admin type of person, so I am still just learning about unoconv and installation issues. I haven't installed it yet, but might do so as soon as I better understand what I am doing. Might you (or others) know the steps of installing this on a CentOS (virtual) server? Are they the same as Debian?
Install on CentOS close but may not exactly the same as Debian ...
See: https://moodle.org/mod/forum/discuss.php?d=329769#p1348115
for how I did it with CentOS 6 (see no reason same shouldn't work with CentOS 7).
Also: https://moodle.org/mod/forum/discuss.php?d=329769#p1348285
for a minimal install of LibreOffice on server.
Box I put it on hosted at a school whose Moodle is behind the schools firewall so no issues with the port for Solr being accessed by the outside world. Am thinking ipchains/tables (server firewall) could be configured to allow localhost and the Moodle's internal IP address access to that port ONLY or an apache proxy could be set up for /solra (solr admin) to point to the solr server but haven't set that up yet. Have setup webmins like that, however, and it does work and works well.
Did a little research on hosting providers and what they allow to be installed or will install ... many won't install java and for sure many will not install a minimal LibreOffice for Moodles on shared hosting. So if Moodlers that have shared hosting who decide to try and upgrade to 3.1 for the features of search and for unoconv ... they probably should be warned they *will* have to go to a VPS ... and to check the fine print on VPS systems hosting as well (provider might not allow certain installations even on VPS systems).
Welcome to do your own leg work on that potential issue.
'spirit of sharing', Ken
Ideally, I would like to experiment on an experimental server, when I find time to buy one. I am not sure if I want to mess with my production Moodle server.
This unoconv seems to be needed only for grading assignments, when wanting to grade by marking up the submittal. It's an interesting new feature (in 3.1), but I am not sure if it will really speed up my process. Right now, I grade assignments by downloading them and downloading the grading (CSV) file. This is working real well.
Thanks for your additional information.
Hi Rick.
Just curious, when you've finished grading with your method, do students get to see your grading markup on their submitted file?
I haven't got unoconv to work yet with Moodle, on my server, but on other servers where it does work, students get to see any marking I may have placed on the files they submit, same as grading with pencil on paper, more or less.
Al, thanks for your question.
Well, no. If I did what to mark up a file I would have to do it on the side, and then email it back to students. Actually, this is the improvement that I am seeking with unoconv. It might be nice to grade an Excel file, for example, by marking it up and having students see my annotations. If I had unoconv working, I would be able to decide which submittals I really need to mark up. Probably my process would be to do exactly what I am doing now, but if I encounter a bad Excel file, I would go back into Moodle and mark it up.
I need to be able to mark up Word, Excel, PDF, jpeg, Visio, MS Project, Access, and probably a few other file types.
Yes, my work-around solution is to take a screen shot of the student's file, mark this up, and send back to the student. But if I could do this in Moodle, Moodle might provide an interesting solution and workflow.
(Also, some other products seem to offer some form of this, such as Canvas. I am not sure if Canvas has its own system or is simply using unoconv, too.)
This is starting to make a little more sense. So if PDFs are submitted by students, the "Grade" feature of Moodle 3.1 will allow for direct markup via Ghostscript. (Sorry to ask, I should just test this myself.)
So what is the scenario if unoconv is installed? Will Ghostscript (via Moodle) convert the file in the background, or will the instructor need to manually do the conversion?
In my case, if I could convert Word and Excel files, that would probably catch around 75-80% of my assignments.
Okay. I think that I am there.
Now I need to either review how to install unoconv in my XAMPP/MAMP environment so that I can practice. I am not sure if there are posts (above or elsewhere) giving the instructions. Also, I am not sure if installing unoconv in XAMPP/MAMP on my Mac provides this ability to my entire Mac, or just isolated to my XAMPP/MAMP environments. I will continue monitoring posts, and find some time to review posts by others.
Thanks much for your help.
(Ken, have you installed unoconv on one of your XAMPP installations? Your thoughts are also appreciated.)
Ok, call me a 'bigot' ... that's OK ... confess I am when it comes to Windows and Internet related web based open source driven apps - like Moodle. Even if Microsoft has purchased a Moodle Partner and they seem to understand now they are NOT the only game in town ... Azure 60% of guest OS's are Linux ... Microsoft now has a Linux of their own to help with Linux guest OS's on Azure ... and heard they are developing a version of MSSQL for Linux and that there is a bash shell environment now available for Windows OS. Ok, enough of that soapbox.
Personally, don't make it a habit of using the localhost apps for Mac or for Windows. Believe they to be mis-leading when one has used Moodle with multimedia ... just like the benchmark test one can run now.
Besides ... getting the entire AMP stack ... the 'P' in that would also mean Perl and Python. While Mac's do come with Python and Perl they are Apple provided versions. perl -V python -V on both your Mac and your remotely hosted Linux box. Issuing those commands on a Windows machine?
Installing those on any platform that doesn't natively use them or could use them is always adventure and what one learns there, may not apply to the production server ... which is on a flavor of Linux. Yes, one could use VirtualBox (or similar) to get an environment like production server but still ... networking comes before application ... one hop away from a source isn't the same as being 10-20 hops away from a source.
So ... having said all that ... I use 'stealthy' virtual apaches that run on a true server for 'sandboxes'. Thus I am working with the same version of PHP, MySQL/MariaDB, Apache + all extensions, etc.. as the production Moodle has access to/is using!
As far as this thread's topic .. unoconv installation a security risk ... think it's run its course. Maybe what's needed is some more explanations in docs for unoconv.
All this to say ... sorry ... don't have any info for ya on XAMPP/local host.
'spirit of sharing', Ken
Includes instructions for installing on Mac. It is a wiki - if you can add to the documentation to help other people please do so.
As others have said, your IT department has provided an answer that meets their needs to secure the server environment within the functional requirements of your organization.
What hasn't been determined is if the functionality you want is needed by your organization or will provide significant value to your operation. If either of these is true, it is up to your organization to tell your IT department that these functions are required and that they need to implement them. There will be a cost associated with that, and they have identified significant parts of that. Once they know these features are required, they will design processes to ensure security and manage these features.
When dealing with security, IT groups want the minimum footprint they can work with. You just need to get these features added to that minimum footprint.
mike
I recently had a sit down with our IT staff and one of the issues they pointed to was found here: https://www.libreoffice.org/about-us/security/advisories/cve-2016-4324/
More on this issue https://www.helpnetsecurity.com/2016/06/30/libreoffice-flaw-godsend-hackers/
Basically, make sure your LibreOffice is up to date if you have it installed.
Yep, same link I found and shared somewhere in this 'discussion' ...
LibreOffice before 5.0.5
But, just like many other security issues .... 1) keep software up-date and 2) if really concerned, read the details as to how a user might be able to exploit. Can't tell you the number of times in M$ security announcements where I read ... 'turn off active X in IE browser'. Like things are possible on the server end.
I happen to help a gentleman with 4 instances of Moodle on a dedicated server and there's a special relationship with the bosses and the server administrator ... true OS server administrator. While this true SA said big on security, actions don't quite 'walk the walk' IF a month has gone by and no yum -y update has been run. Pretty easy to say no and give a generic 'for reasons of security' answer. That day an age is now fading ... why? For the first time many things are being driven (for better or worse) by the user ... ie, smartphones, tablets., etc.. If the boss owns an iPhone and wants to see/use Moodle, then something will be done ... or attempted at least!
Yes, no one should *NEVER* take server security lightly ... but we also don't need to go overboard the other way ... and say no just because we find *one* reference - especially if that isn't researched and evaluated.
'spirit of sharing', Ken
I'm just going to say that this is probably the stupidest decision that I've seen out of Moodle...it dramatically increases the complexity of what used to be the Simplest Software Installation Ever, dramatically magnifies the attack vectors that you're exposed to, and requires unnecessary amounts of server resources.
I don't see what was so bad about the previous way of doing things? It seemed to work fine for everyone we've talked to.
And, not to mention that installing an office suite on a server is such a terrible idea that it's not even an option in the default repositories of a lot of dedicated server OSes... To the extent that if we were looking at installing Moodle for the first time today, I'd have to throw up red flags, as most sysadmins should also do.
This makes me very disappointed in the Moodle team, for the first time in a decade of using the product :'(
Not to mention that the whole unoconv issue converts a document from one format to another. No guarantee that the same fonts will be available. No guarantee that the same format the user has used in their Word 2016 will look the same in the converted document.
The fact that you are converting someone's document to another format in this way changes the look of the document in ways that could give a student adequate grounds to say "You modified my document! I do not accept your comments/grade as you are not grading the work I submitted!". It may be an extreme case, but in instances where presentation are assessed the whole system becomes totally useless imo.
Hi Chris,
It's worth bearing in mind that Unoconv is an optional extra for Moodle. If you don't want it, or have concerns about it, then you do not need to configure it and Moodle will continue to work as before. The setup is no more complicated than it was, unless you want to use Unoconv.
Unfortunately document conversion is not an easy task, and it's certainly not something that Moodle should be directly responsible for.
There are a range of methods to convert documents, but most of them are OS-specific, or involve integration with external services. Unoconv is one of the few exceptions to this.
It is also possible to run Unoconv in a client/server mode so that you do not need to run LibreOffice on your web-facing server.
You may also be interested in MDL-55528, which will be available in Moodle 3.3, and which moves the conversion of files to a new plugintype opening up alternatives to Unocov. We also have MDL-58280 which we hope to include in the next week or so, which will provides a new Google Drive converter available in core as one such alternative.
Andrew
Problem is, at least in my memory for looking at it last August, this isn't quite true.
Yes, you can just not configure it. If you don't you just get instead a large white blank screen indicating something is "missing". This certainly isn't "as before". Sure you can ignore this. You can even configure it so the pdf grading view doesnt appear ever but this doesn't help if you have in the past used any pdf grading as this removes this option entirely if you hide the ugly white box.
The best solution I have heard so far - and one that I will likely implement when I am forced to upgrade to 3.1 or later this summer (I held back from 3.1 last summer simply for this issue alone) is to ONLY accept PDF submissions from students when uploading documents. If students only ever upload PDF submissions there will be no conversion, and no need to run a ridiculous bleeding edge document converter. Bleeding edge? Yes it is! When I looked at this last year unoconv had to be compiled from source as the version needed wasn't even in repositories yet - but STILL this was released. In my view this is reprehensible and a worrying sign. I do hope Moodle HQ are not going to get into the habit of releasing versions of Moodle that rely on code that hasn't even been adopted by distribution maintainers!
Totally agree with Tim. We are also struggling with this:
" If you don't you just get instead a large white blank screen indicating something is "missing". This certainly isn't "as before". Sure you can ignore this. You can even configure it so the pdf grading view doesnt appear ever but this doesn't help if you have in the past used any pdf grading as this removes this option entirely if you hide the ugly white box."
At the very least, is there a way to change the default view so the non-PDF view is displayed and the PDF annotation view is launched only when a PDF is attached?
You also mention that this can be client/server setup to minimise the impact to the Moodle server. However I would question the logic behind introducing functionality that requires such an extra load on server resources to the extent that it is even suggested making a Moodle server into a two server setup. To do so simply to leverage an inherently dodgy function (converting a document and making it different to the submitted one) is at best questionable. Optional or not this smacks of finding a solution to a problem that doesn't exist and making the whole structure vulnerable to collapse.
Is there a way to change the default setting so the review panel is collapsed by default and the instructor can make the choice to expand it? Better yet, if it recognized a PDF and opened in the expanded view only then.