On Mon, Jul 17, 2017 at 07:14:07AM +0200, Guillaume MM wrote: > Le 05/07/2017 à 06:54, Scott Kostyshak a écrit : > > 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. > > I think the topic is very relevant. This is about allowing arbitrary > code execution with user's privileges from a file possibly shared in > collaborative settings.
Good point. I read it now. > > 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. > > > > > First, thanks a lot. I find reassuring to see you making this effort. > Maybe that you better see my point of needauth not being ready for more > unsafe features yet, and also what could be done to get past this point. > I hope that you also understand my reluctance to do so in a hurry before > beta release. I think I am getting a better understanding. I think your reasoning is something like "since this is a security issue, let's wait until we're very confident we won't decrease security". I think that is a completely reasonable approach. But my approach is more simple of "which of the above three options (mentioned at the top of this email) leads to the most secure user experience in 2.3.0?". > There are two points that I do not see reflected in your discussion > above, though: > > * I believe that there are two distinct populations: users who went to > customize their configuration, maybe following 3rd party guides, and > other users who did not, but who solely by the interface are > promised (durable) minted support and encouraged to use it. Users who > go to the extent to customize their configuration should be provided a > safe way to do so in any case, and I wish that needauth is improved in > this regard. I think I see what you mean, and agree that it would be great if needauth were improved as discussed in the other threads such as using apparmor. > * The guide above is about *how* to offer compromises between security > and usability but another question with minted.sty for me was *why* > compromising in the first place. I was thinking about it from a different angle. I was only focused on what I thought was most secure, without even considering usability. As I mentioned in the thread asking for votes, I believe that we should focus completely on what is the most secure. > But besides that I agree with your suggestions. Thanks again for > spending your time looking into this issue with so much care. I've actually enjoyed it since I've learned a lot about security issues. I think that guide you linked to gives a great abstract framework to think about security. Adapting the abstract guidelines to specific discussions is the challenge. Scott
