Talk:Security

Jump to: navigation, search

Note: You are currently viewing documentation for Moodle 1.9. Up-to-date documentation for the latest stable version is available here: Security.

set default for courses enrollable to 0

This might also go in the "miscellanceous section". In cases where all students are enrolled by the administrator, would it not be effective to set the default for courses being enrollable to 0? I assume that instructors or admins could continue to enroll students manually or through an automated process, but students would no longer be able to enroll themselves through searching the course list.

If I am interpreting this correctly, I would add something like this to the section:

open the files moodle/course/edit_form.php

go to line 164 which starts with: $mform->addElement('header','enrolhdr', get_string('enrolments'));

and write just above it the sentence

if (iseditingteacher()) {

goto line 238 and write the following just below

$mform->setDefault('enrolperiod', 0);

} // close ifiseditingteacher

This code might not be quite right--I copied it from this discussion http://moodle.org/mod/forum/discuss.php?d=55702 but, at least in our case, we would want to retain teacher rights to adjust student enrollment manually.

If this is totally incorrect, please advise.

awyatt

Enrollment key hint

In my mind, the enrollment key hint is a security problem (because this is under the control of instructors who, in my experience, do not use hard-to-guess keys). The hint is not robust enough to really help a student if a "good" key has been set (and we wouldn't want it to be!). I think editing the enrolmentkeyhint string in moodle.php is a good short term solution until more robust key management is introduced into core (I noticed several items in the tracker, so I expect this will be looked at in future releases):

 $string['enrolmentkeyhint'] = 'That enrolment key was incorrect, please try again. 
 Contact your instructor if you need assistance.';

I will not take credit for this idea; that belongs to Steve Hyndman. I think it is a simple change and admins should be encouraged to make it.

awyatt

Thanks atw, the security page now includes information on removing the enrolment key hint. --Helen Foster 04:05, 28 August 2008 (CDT)

A quick way to change file / directory permissions & owner / group:

        find -type f -exec chmod 640 {} \;
        find -type d -exec chmod 750 {} \;
        chown -R root:apache *

Mark Laffoon

Little spelling error in opening paragraph."involving some conbination of input" should be combination, not conbination.

Thanks, it's fixed. --Helen Foster 05:46, 15 March 2007 (CDT)


Should this page deal with valid users as well? I'm talking about input sanitization, etc. For example, in my school's version of Moodle, I can craft some code that logs the user out as soon as they see my forum post. I suggest taking a look at MediaWiki's approach to code sanitizing. -- Tim McCormack is Tim McCormack 12:45, 11 February 2006 (WST)

Tim, I believe what you are mentioning is actually related to the future development of Moodle code, or possibly an existing security bug? There is actually a lead Security Officer, Petr Škoda (skodak), who is charged with reviewing the security code. He would probably like to see an example of what you mentioned. Jonathan Moore Jonathan Moore 8:46, 12 February 2006 (CST)
I have reported it in full detail at the security.moodle.org site. -- Phyzome is Tim McCormack 09:29, 16 February 2006 (WST)

Please, take a look at the "Before all" topic I have just added, based on Petr's opinion on this: http://moodle.org/mod/forum/discuss.php?d=39404#182024 - David Delgado 02:11, 13 February 2006 (WST)

I have updated the file permissions, with what I hope are more correct values. Moorejon Jonathan Moore 10:52, 14 February 2006 (CST)

Security for Security page

Maybe we should take a look at the security in this "Security" page. :-/ Should it be a protected page maintained directly by http://security.moodle.org? Please, give us your opinion on this in the "page comments" label in this page.

I do think it SHOULD be protected and maintained directly by http://security.moodle.org , since it is the best place to introduce security hazards. Just add "Do not forget to send your admin password to safe@cracker.com", for example. Think also of more sophisticated cracking methods. By the way... moodledata directory owned by root with 700 permissions, Moorejon? :-/ - David Delgado 16:44, 13 February 2006 (WST)
I think you make a good point. At a minimum this page needs to be monitored by someone. I think more subtle problems than the send password to x variety could be introduced too. Such as changing the permission numbers or some such.
Since I am not a member of security.moodle.org, I can't speak for them. I don't know what all of their duties entail and whether there is a complete match up with what they cover for Moodle and what is covered in the guide.
Page protected, as requested. Please use this page for suggesting changes to Security. --Helen Foster 19:06, 16 February 2006 (WST)

Running Moodle with PHP safe_mode=on

Does any security guru dare to document that? I think it is possible to do that (both to run Moodle with safe_mode=on and to write the document). ;-)


What About System Validation Audit Trails?

I am a physician in a medical laboratory doing both commercial and clinical trials (FDA regulated) diagnostic studies on a global basis. We are redesigning our entire validation, documentation and training systems and I am in the process of using MOODLE to manage the training process. I have a very computer savvy employee who used to be the administrator for the ANGEL LMS from Indiana Universiy (that is now a commercial product).

Now here is the delimma, everything even remotely associated with Clinical trials and even routine medicine is getting extremely regulated and we virtually are inspected 12+ times a year (1-4 day audits). With Part11 regulations ALL software (developed or off the shelf) has to have a full system validation. The FDA has moved this to a risk-based processes, so intense validation is in basically critical data where users have access to alter data. We develop our own LIS (Laboratory Information System) because you cannot get OTS software with functionality to work in clinical trials. Thus we have a small team of (pharmaceutical business experienced) validation personnel. So we will do something in this area. However it would be extremely helpful if others had done some of this work to share some use case examples and any outcomes or known areas of system weakness. The FDA is also very strongly into electronic audit trails, is that possible in MOODLE?

Since I am new to this software, I am just starting to explore it, but would welcome any experience in this area. We will sure share our experience with others becuase this type of software has a much broader application that just in educational institutions. (I was also the medical director of a fully ACCME accredited non-profit post-graduate medical education company that had over 5,000 medical technologist and physician subscribers. That company was sold to the largest CME provider for laboratory professionals in the world, ASCP).

Mick Glant, MD Indianapolis, IN

Hi Mick, assuming you've not done so already, please post in one of the forums in Using Moodle. --Helen Foster 04:05, 28 August 2008 (CDT)

Add documentation for enforcement of password complexity

Helen - MDL-8031 (an improvement in Moodle 1.9) implemented the ability for an administrator to enforce passwords to meet certain criteria. Under the comment about using "good passwords" it would be nice to add a 1.9 tag with an explanation of how this works. It will be in the Site Administration block under Security/Site policies. There will be a check box to determine if password complexity should be enforced or not, the ability to set the minimum length of the password, the minimum number of digits, the minimum number of lowercase characters, the minimum number of uppercase characters and the minimum number of non alphanumeric characters. If a user enters a password that does not meet those requirements, they are given an error message indicating the nature of the problem with the entered password. Enforcing password complexity along with requiring users to change their initial password go a long way in helping to ensure that user's choose and are in fact using "good passwords". Let me know if you have any questions. Peace - Anthony

Thanks Anthony, I've added a password policy section to the security page, as suggested. --Helen Foster 15:55, 7 August 2007 (CDT)

Link to french version

Could someone link this to the french version of the page, here : [1]

Thanks in advance

--Nicolas Martignoni 12:09, 14 August 2007 (CDT)

Thanks Nicolas, fr link added as requested. --Helen Foster 13:12, 14 August 2007 (CDT)

Rework the most secure/paranoid file permissions section

The permissions detailed in that section are only applicable to those running their own servers, but they are not suitable for people running moodle in shared hosting enviroments. In many of those hosted environments the web server is running under a 'client' user account, and not www-data/httpd/apache/etc. Changing the permissions to those specified in that section actually prevents moodle from working (see [2] for an example).

It's difficult to give suitable permissions for hosted environment moodle users, as different hosting providers offer quite different web service configurations.

Iñaki Arenaza 17:33, 27 July 2008 (CDT)

(I agree Petr Škoda (škoďák)skodak)

Added a new section for people running Moodle on share hosting environments, with some hints to determine the most secure set of permissions Iñaki Arenaza 06:15, 2 August 2008 (CDT)

Introduction section inaccurate?

The introduction seems to suggest bugs should be reported to security.moodle.org and NOT on the tracker - but going to security.moodle.org takes you to a forum post that says you SHOULD post on the tracker. The page is protected so I can't update it myself, perhaps someone else would care to? Nigel McNie 23:02, 2 November 2008 (CST)


I fixed this  Martin Dougiamas 00:28, 3 November 2008 (CST)

Managing expectations

Thinking about some recent rants and raves, should something be said about managing expectations in Moodle. My line has been "Moodle isn't a banking application". In particular, don't put anything sensitive in a course files area as it isn't secure, deleting users doesn't delete them and it *may* be possible to continue to link to the data, switch off email based authentication, don't use guest access, set up some sort of access control on newly created courses etc. --Howard Miller 09:11, 3 November 2008 (CST)

Typo: rpd instead of RDP

There's a typo in the part where is described ports to be open for remote access: it says "rpd port 3389", and it must says "RDP port 3389".

I try to fix it myself, but I have no edit permission in this wiki.

Thanks

Vicente, thanks for pointing out the typo, which I see Petr has fixed. --Helen Foster 14:19, 11 December 2008 (CST)
Not if RDP is supposed to be all upper case. --Richard Enison 20:27, 7 November 2009 (UTC)

Broken link

The link to the Windows Root Kit Revealer in the section "Be prepared for the worst" is broken. --Richard Enison 20:23, 7 November 2009 (UTC)

Add a privacy section to Security

Can I suggest that we add a Privacy section to this Security page.

It applies particularly to jurisdictions subject to the UK Data Protection Act and the US FERPA legislation.

Mark Berthelemy

I feel that a separate but linked page would work better.--Tim Hunt 14:07, 14 February 2011 (UTC)