Details

    • Type: Sub-task Sub-task
    • Status: Closed
    • Priority: Minor Minor
    • Resolution: Fixed
    • Affects Version/s: 1.9.3
    • Fix Version/s: 1.9.5
    • Component/s: Administration
    • Labels:
      None
    • Affected Branches:
      MOODLE_19_STABLE
    • Fixed Branches:
      MOODLE_19_STABLE
    • Rank:
      33578

      Description

      On a large site with more than 3600 users, the Security report shows "Found 2353 Users that must be trusted". This means that almost all users enrolled in any courses must be trusted.

      The only override student role has is about viewing participant and user profile (set to prevent).
      The only override Authenticated users has is about completing and entering feedback, set to Prohibit.

      Looks like it is very dangerous to enroll students, beside the suggestion to verify trust of the very long list of 2353 users.

        Issue Links

          Activity

          Hide
          Koen Roggemans added a comment -

          I have 182 trusted users on an 1749 users site. Are those users the teachers?

          Show
          Koen Roggemans added a comment - I have 182 trusted users on an 1749 users site. Are those users the teachers?
          Hide
          Andrea Bicciolo added a comment -

          Koen, most probably yes. Teacher role must be trusted, according to the new Security report.

          Show
          Andrea Bicciolo added a comment - Koen, most probably yes. Teacher role must be trusted, according to the new Security report.
          Hide
          Martin Dougiamas added a comment -

          I agree this isn't useful at all. People can't do anything with this information.

          I can't see how we can explain usefully about the risks here on this display. We probably should have a risk report that is separate and lists all the risky capabilities with information for each one.

          My vote to remove it from this report and implement it as a separate risk report (after 1.9.4)

          Show
          Martin Dougiamas added a comment - I agree this isn't useful at all. People can't do anything with this information. I can't see how we can explain usefully about the risks here on this display. We probably should have a risk report that is separate and lists all the risky capabilities with information for each one. My vote to remove it from this report and implement it as a separate risk report (after 1.9.4)
          Hide
          Martin Dougiamas added a comment -

          A table listing all the risky capabilities could also go on the detail page, of course.

          Show
          Martin Dougiamas added a comment - A table listing all the risky capabilities could also go on the detail page, of course.
          Hide
          Petr Škoda added a comment - - edited

          This is caused by a bug in Feedback contrib module.

          I do not agree that the info here is useless - assigning teacher roles is VERY risky and it is the most important info from this report.
          I already have a solution for this for several years - it is the trust bitmask in user record - it would mark all users that are trusted and they would not appear on this report any more

          Show
          Petr Škoda added a comment - - edited This is caused by a bug in Feedback contrib module. I do not agree that the info here is useless - assigning teacher roles is VERY risky and it is the most important info from this report. I already have a solution for this for several years - it is the trust bitmask in user record - it would mark all users that are trusted and they would not appear on this report any more
          Hide
          Martin Dougiamas added a comment -

          Well, that sounds good to me!

          Show
          Martin Dougiamas added a comment - Well, that sounds good to me!
          Hide
          Andrea Bicciolo added a comment -

          On either Moodle site assigning Teacher is probably one of the most common task. I think we all agree that without teacher role assigned at least at course level, there is very few sense on using Moodle.

          If the above assumption holds true, and if currently assigning teacher role (even at course level) is very risky, then we need to find a solution to let people assign teachers without such risks.

          Imagine a Large institution with hundreds of courses and teachers, like a large university: how an Admin can be absolutely sure all teachers are trustworthy? I think we all know it is impractical in the real world, and we could end up with institution than do not want to assume risks and start to think to Moodle alternatives.

          Show
          Andrea Bicciolo added a comment - On either Moodle site assigning Teacher is probably one of the most common task. I think we all agree that without teacher role assigned at least at course level, there is very few sense on using Moodle. If the above assumption holds true, and if currently assigning teacher role (even at course level) is very risky, then we need to find a solution to let people assign teachers without such risks. Imagine a Large institution with hundreds of courses and teachers, like a large university: how an Admin can be absolutely sure all teachers are trustworthy? I think we all know it is impractical in the real world, and we could end up with institution than do not want to assume risks and start to think to Moodle alternatives.
          Hide
          Petr Škoda added a comment -

          I think we would get Nobel prize if we solved this general problem of security of web applications
          There is 0% chance we can secure flash, java and other files uploaded by editing teachers, sorry.

          On the other hand we might try harder to make at least non-editing teachers more "safe" in 2.0.

          There are no "safe" alternatives, other open/closed online education platforms have exactly the same problems - the SCORM standard itself requires Javascript, so any product that supports SCORM or Flash must be vulnerable too.

          Show
          Petr Škoda added a comment - I think we would get Nobel prize if we solved this general problem of security of web applications There is 0% chance we can secure flash, java and other files uploaded by editing teachers, sorry. On the other hand we might try harder to make at least non-editing teachers more "safe" in 2.0. There are no "safe" alternatives, other open/closed online education platforms have exactly the same problems - the SCORM standard itself requires Javascript, so any product that supports SCORM or Flash must be vulnerable too.
          Hide
          Andrea Bicciolo added a comment -

          I agree with teh nobel prize .

          Anyway, think about the feelings of institutions using Moodle that warns them telling they are doing Very Risky things.

          Show
          Andrea Bicciolo added a comment - I agree with teh nobel prize . Anyway, think about the feelings of institutions using Moodle that warns them telling they are doing Very Risky things.
          Hide
          Petr Škoda added a comment -

          If we add UI for user trusts then we can mark users as "trusted" and they will not be listed in the report - that way if you configure the trusts properly you would not have this ugly warning.
          Would this help?

          Show
          Petr Škoda added a comment - If we add UI for user trusts then we can mark users as "trusted" and they will not be listed in the report - that way if you configure the trusts properly you would not have this ugly warning. Would this help?
          Hide
          Andrea Bicciolo added a comment -

          Well, this could be interesting. A sort of way to "validate" user trust. I'm sure someone would like it

          On the opposite, the user trust flag could also be a job for people other than admins (I again refer to large institutions). This would create the need for a capability that could be assigned to a "Security Officer" role, or the like.

          Show
          Andrea Bicciolo added a comment - Well, this could be interesting. A sort of way to "validate" user trust. I'm sure someone would like it On the opposite, the user trust flag could also be a job for people other than admins (I again refer to large institutions). This would create the need for a capability that could be assigned to a "Security Officer" role, or the like.
          Hide
          Petr Škoda added a comment -

          closing and filing new issue for trusts,

          thanks for the report!

          Show
          Petr Škoda added a comment - closing and filing new issue for trusts, thanks for the report!

            People

            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: