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

      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.

        Gliffy Diagrams

          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 Skoda 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 Skoda 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 Skoda 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 Skoda 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 Skoda 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 Skoda 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 Skoda added a comment -

            closing and filing new issue for trusts,

            thanks for the report!

            Show
            Petr Skoda 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: