If my stories are blocked, should I take on a new story?

I have a QA role on a scrum software project, and all my current stories are related to testing the front-end UI

There's your problem. In Scrum there is no QA role. There is an accountability, shared by the Developers, of which you are one. You are a developer because your work is needed to deliver a Done and usable increment no later than the end of each Sprint. That's the commitment which you and the other Developers make.

Seen in that light, do you really have your own QA "stories" at all? If so, why? Doesn't a story represent a conversation you and the others must have, collaboratively, in order to produce something of value for stakeholders?

Wouldn't it therefore be better for Developers to stop starting any new work they are jointly accountable for, and start finishing the work which is already in progress?

You do not have stories.  The Scrum Team has stories and the Developers have selected a subset of stories that are included in the Sprint Backlog that are needed to reach the Sprint Goal.  As @Ian points out, in the Scrum framework, you are a Developer.  Since there has been a commitment made by the Developers to a Sprint Goal, would it make more sense for you to help the Developers achieve the goal that has already been set instead of focusing on yourself to make sure you have work?

In addition to the comments from @Ian and @Daniel, there are no stories in scrum. Agile has stories, scrum does not. So, there is no such thing as "pulling a new story" in scrum, and your scrum team is violating the Scrum Guide's intent of "Each element of the framework serves a specific purpose that is essential to the overall value and results realized with Scrum. Changing the core design or ideas of Scrum, leaving out elements, or not following the rules of Scrum, covers up problems and limits the benefits of Scrum, potentially even rendering it useless."

@Polina Blintsovskaya Ian and Daniel made great posts above. I would add one thing to clarify something more, that maybe puzzled you after reading those posts:

As Scrum does not identify such roles as QA, it does not identify also such roles as CEO, Front-end programmer, Architect etc. It does not mean that such roles do not exist - it simply means, that from the Scrum perspective we focus on another aspect than a particular role. Hence the term accountability.

It is perfectly normal that you recognize yourself as a person with the QA role within the team, in most cases that I faced that was a thing. The trick on the other hand is to understand that having a particular role such as QA, shouldn't limit you from collaborating with other team members to the best of your capabilities in order to achieve the Sprint Goal.

You can imagine a soccer team, if the game unfolds in a way that the defenders have little to do on their own half of the field, does not mean that they go to play somewhere else, or start to kick another ball for training purposes. No, they will stay focused to take action immediately when needed, and they will advance down the field to help other teammates to the point it makes sense.

So what you could do in that situation? For example, you could rise this situation with other team members and propose few what you (together) could do to increase chances for achieving the Sprint Goal and creating the Increment, it may be for example:

• Pair programming with someone?
• Maybe it is worth doing as much QA as possible in your local environment while DevOps issues are tackled?
• Maybe you could check with other members test scenarios, or write some automates that will run when DevOps issues will be cleared?
• If there is nothing reasonable to do to help others with what you have within the sprint, then you could check the top of the Product Backlog and refine items there (if needed) - refinement doesn't have to be done with the whole team present. To some degree, it can be done alone or in a smaller sub-group.
• Maybe it would be good to start thinking about Sprint Review and what would you prepare as a team to make this event a valuable Inspection and Adaptation opportunity?

I mentioned only a few things that you may consider instead of pulling in something extra to the Sprint.

In such situations, the whole team should be careful with taking on new work only to be busy. In the vast majority of situations, work can not be done by one person from start to finish. Imagine that you will pull extra work to the sprint, if you find some bugs (assuming that you will focus on QA), you most likely return the item to another developer, so that he or she can correct it, which usually will lead to another peer review of changes, etc. If for any reason it will not be tackled, your work has a risk of becoming waste, as with each further change introduced with another work, there is a chance that what you possibly found will no longer be valid.

Just because you feel that you have some more capacity to do stuff, does not mean that others also have such possibility to accommodate extra work, and possibly dilute their focus by that.

Another risk is, that such work pulled into the sprint often spills over. Such spillovers, aka not finished work, impact the team's ability to craft cohesive Sprint Goal and effectively plan the Sprint. It rarely is a case that the PO makes a call that spillovers are out of the table, for example, due to Sunk cost fallacy effect.

So generally speaking, taking extra work to the Sprint should be the very last action to do. But that does not mean that you should sit and do nothing, just focus your efforts on either helping the rest of the team to create Increment and achieve the Sprint Goals as best as you can, or focus on actions that will help the team do valuable and effective upcoming events, such as Sprint Review, Sprint Retrospective, and Sprint Planing ;)

My scrum team has a strict policy about not pulling in new stories mid-sprint and not to pull in new stories until previous ones are completed and closed.

Why not?

Carefully considering not endangering the Sprint Goal, avoiding the potential waste previously mentioned and the danger of unsustainable pace, sometimes there could be room for a valuable item that's not in the Sprint. Perhaps you're not able to help your colleagues with the things they work on and there's something of good value waiting in the Product Backlog.

Why not raise this particular issue, say, in the Scrum Daily and see what others think of it? And if the feedback is positive, why not negotiate it with the Product Owner?

Why not discuss the policy itself in the Scrum Retrospective if you think the way you work could be improved?