On Wed, Jun 28, 2017 at 02:37:41PM +0200, Guillaume MM wrote: > Le 27/06/2017 à 21:00, Scott Kostyshak a écrit : > > > > Where I > > think there is disagreement is on whether we take a paternalistic > > approach of "are you sure you know what you're doing? Think very hard > > about this before you do it" or a lax approach of allowing users to > > shoot themselves in the foot. Should we treat LyX users like teenagers > > or adults? I really don't know the answer. > > I am in favour of treating lyx users like adults. To me, this means not > reinventing the wheel and follow established guidelines. See e.g. > > https://developer.apple.com/library/content/documentation/Security/Conceptual/SecureCodingGuide/Articles/AppInterfaces.html > > and the paper they mention which has a lot of examples.
That's a great article. Thanks for the link. I've thought about a lot of the principles mentioned in the article in the context of each of what I view as the three options for moving forward: 1. Revert the recently added minted support. 2. Keep the current state of master. 3. Apply the patch from [1]. Below, I will refer to these three options by their numbers above, e.g. (1), (2), and (3). Of course, the quotes I choose and my analysis of whether each option "passes" or "fails" a criterion are completely subjective. Starting at the section <<Use Secure Defaults>> "In many cases, a simpler interface is more secure, because the user is less likely to ignore security features and less likely to make mistakes." (1) fails: implementing minted through custom preamble code and ERT is not simple (2) at least the user only needs to do the "shell-escape dance", which is what I refer to going to Tools > Preferences > File Handling > Converters, adding "-shell-escape" (remembering whether "shell-escape" is preceded by one dash or two dashes), clicking "Modify", and then finally clicking "Apply" or "Save" (which I believe is a separate source of confusion for the users). (3) passes: it is simple to read the dialog and click on the button. Moving on to the section <<Meet Users' Expectations for Security>> "The user must be made aware of when they are granting authorization to some entity to act on their behalf or to gain access to their files or data." (1) fails: when the user does the "shell-escape dance" they are not given any dialog making them aware of the potential dangers. You might think "well they are adding it themselves so they should already know", but I would say that most users are probably following some unofficial guide they saw on the internet and just copy/pasting stuff in without thinking. (2) same as (1) (3) passes: there is a dialog with an explanation. "In this case, sharing should be off by default." (1) - (3) all pass. "If the user turns it on, the interface should make clear the extent to which remote users can read from and write to files on the local system." (1) fails: there is no dialog. (2) fails: no dialog (3) passes "In addition, as long as sharing is on, there should be some clear indication that it is on, lest users forget that their files are accessible by others." (this was also brought up by Guillaume at [2]) (1) - (3) all fail. I think that (3) has the most potential for implementing a visual indication, unless we want to parse the converter command for "shell-escape". "Authorization should be revocable" (1) passes (2) passes (3) fails: if the user puts "Always allow for this document", it is not easy to revoke. The user must know something about the sessions file, which they should not be expected to know. We could put instructions for how to remove access. I'm not sure if I agree with adding even more text to the dialog though. Tommaso mentioned some ideas regarding revocation in the context of needauth at [3]. "Whenever possible, your program should not only make this possible, it should make it easy to do." (1) - (2) fail because of the "shell-escape dance" and (3) fails because of the sessions file. "You should also make it clear that revoking authorization cannot reverse damage already done" I don't understand this. In our case would this mean that if the user removes "shell-escape" we give a dialog saying "the previous compilations you did with this compiler could have run malicious code" ? If so, I think that might confuse users more than benefit them. Moving on to the section <<Secure All Interfaces>> Not much to talk about here. (3) does work as I expected when I tested on the command line. Moving on to the section <<Place Files in Secure Locations>> I think that (1) - (3) all fail this. Preferences and sessions files are stored in plain text that can be easily edited. I think we could improve this by storing them somewhere else where the user doesn't have permissions, but I suppose we will always want to allow the user to edit their preferences with an external editor, and backup/restore preferences files. So I'm not sure if there's a feasible way to address this. I think that (3) fails this a little more than the others, because the sessions file is one more file (in addition to preferences) that if a malicious user is able to gain access to somehow they could add -shell-escape permissions. However, I currently don't see a situation where a malicious user could get access to sessions file and not preferences file. Moving on to the section <<Make Security Choices Clear>> "when giving the user a choice that has security implications, make the potential consequences of each choice clear" (1) fails: no dialog when adding "-shell-escape" to converter (2) fails: same as (1) (3) passes, but I think there is room for improvement. Is "can execute arbitrary commands" too technical? A user might not know what a "command" is. We could say something more user-friendly like "your files could be stolen or deleted". Or, following some suggestions in the guide's text, something like "if you were sent this LyX file from someone you do not completely trust, do not click allow". I did not read the section <<Fight Social Engineering Attacks>> as I didn't think it was relevant. After thinking deeply about this issue from many different perspectives (thanks to the Apple developer guide), I also like to take a step back. In the end, I keep coming back to what I think was Jürgen's point that if the user is forced to do the "shell-escape dance", they will often forget or be too lazy to remove the option when it is no longer needed. LyX currently forces the user to make a global preference change. Further, LyX does not warn the user when manually adding the shell-escape option. > > I agree that it is late in the process, and indeed that does make > > stronger the proposal of "let's just revert". But this issue is not the > > only one holding up beta1. When we make progress on the other issues, if > > this one is still hanging in the air and we cannot agree on what to do, > > then we might need to move on and revert. My opinion is that we're not > > there yet. > > What is your schedule in either case for implementing and testing the > changes? If 2 or 3 make it into beta1, my plan would be to email some LyX + minted users and ask them to test beta1 when it is released. Scott [1] https://www.mail-archive.com/search?l=mid&q=20170620203439.GC1008%40GIOVE [2] https://www.mail-archive.com/search?l=mid&q=oi9r49%24hn2%241%40blaine.gmane.org [3] https://www.mail-archive.com/search?l=mid&q=2dda131c-da13-8f24-5054-b93529c3f1f8%40lyx.org
signature.asc
Description: PGP signature
