Searcharxiv⌕ Search

arXiv subjects

Joseph Hallett

Publications and source records attributed to Joseph Hallett.

12 recordsLinked to original sources
arXiv2025

Not quite a piece of CHERI-cake: Are new digital security by design architectures usable?

A digital security-by-design computer architecture, like CHERI, lets you program without fear of buffer overflows or other memory safety errors, but CHERI also rewrites some of the assumptions about how C works and how fundamental types (such as pointers) are implemented in hardware. We conducted a usability study to examine how developers react to the changes required by CHERI when porting software to run on it. We find that developers struggle with CHERI's display of warnings and errors and a lack of diverse documentation.

cs.CR↗
arXiv2025

Threadbox: Sandboxing for Modular Security

There are many sandboxing mechanisms provided by operating systems to limit what resources applications can access, however, sometimes the use of these mechanisms requires developers to refactor their code to fit the sandboxing model. In this work, we investigate what makes existing sandboxing mechanisms challenging to apply to certain types of applications, and propose Threadbox, a sandboxing mechanism that enables having modular and independent sandboxes, and can be applied to threads and sandbox specific functions. We present case studies to illustrate the applicability of the idea and discuss its limitations.

cs.CR↗
arXiv2025

Playing in the Sandbox: A Study on the Usability of Seccomp

Sandboxing restricts what applications do, and prevents exploited processes being abused; yet relatively few applications get sandboxed: why? We report a usability trial with 7 experienced Seccomp developers exploring how they approached sandboxing an application and the difficulties they faced. The developers each approached sandboxing the application differently and each came to different solutions. We highlight many challenges of using Seccomp, the sandboxing designs by the participants, and what developers think would make it easier for them to sandbox applications effectively.

cs.OS↗
arXiv2024

RTFM: How hard are IoT platform providers making it for their developers?

Internet of Things (IoT) devices routinely have security issues, but are the platform designers providing enough support to IoT developers for them to easily implement security features for their platforms? We surveyed the documentation, code and guidance from nine IoT manufacturers to look at what guidance they provided for implementing three security features required by several security standards (secure boot, device identity keys and unique per device passwords). We find that more needs to be done to support developers if we want them to adopt security features -- especially in the face of incoming legislation that will require developers to implement them.

cs.CR↗
arXiv2024

Saltzer & Schroeder for 2030: Security engineering principles in a world of AI

Writing secure code is challenging and so it is expected that, following the release of code-generative AI tools, such as ChatGPT and GitHub Copilot, developers will use these tools to perform security tasks and use security APIs. However, is the code generated by ChatGPT secure? How would the everyday software or security engineer be able to tell? As we approach the next decade we expect a greater adoption of code-generative AI tools and to see developers use them to write secure code. In preparation for this, we need to ensure security-by-design. In this paper, we look back in time to Saltzer & Schroeder's security design principles as they will need to evolve and adapt to the challenges that come with a world of AI-generated code.

cs.SE↗
arXiv2024

Sandboxing Adoption in Open Source Ecosystems

Sandboxing mechanisms allow developers to limit how much access applications have to resources, following the least-privilege principle. However, it's not clear how much and in what ways developers are using these mechanisms. This study looks at the use of Seccomp, Landlock, Capsicum, Pledge, and Unveil in all packages of four open-source operating systems. We found that less than 1% of packages directly use these mechanisms, but many more indirectly use them. Examining how developers apply these mechanisms reveals interesting usage patterns, such as cases where developers simplify their sandbox implementation. It also highlights challenges that may be hindering the widespread adoption of sandboxing mechanisms.

cs.SE↗
arXiv2024

Super Mario in the Pernicious Kingdoms: Classifying glitches in old games

In a case study spanning four classic Super Mario games and the analysis of 237 known glitches within them, we classify a variety of weaknesses that are exploited by speedrunners to enable them to beat games quickly and in surprising ways. Using the Seven Pernicious Kingdoms software defect taxonomy and the Common Weakness Enumeration, we categorize the glitches by the weaknesses that enable them. We identify 7 new weaknesses that appear specific to games and which are not covered by current software weakness taxonomies.

cs.CR↗
arXiv2023

Decisions & Disruptions 2: Decide Harder

Cyber incident response is critical to business continuity -- we describe a new exercise that challenges professionals to play the role of Chief Information Security Officer (CISO) for a major financial organisation. Teams must decide how organisational team and budget resources should be deployed across Enterprise Architecture (EA) upgrades and cyber incidents. Every choice made has an impact -- some prevent whilst others may trigger new or continue current attacks. We explain how the underlying platform supports these interactions through a reactionary event mechanism that introduces events based on the current attack surface of the organisation. We explore how our platform manages to introduce randomness on top of triggered events to ensure that the exercise is not deterministic and better matches incidents in the real world. We conclude by describing next steps for the exercise and how we plan to use it in the future to better understand risk decision making.

cs.CR↗
arXiv2021

Don't forget your classics: Systematizing 45 years of Ancestry for Security API Usability Recommendations

Producing secure software is challenging. The poor usability of security APIs makes this even harder. Many recommendations have been proposed to support developers by improving the usability of cryptography libraries and APIs; rooted in wider best practice guidance in software engineering and API design. In this SLR, we systematize knowledge regarding these recommendations. We identify and analyze 65 papers spanning 45 years, offering a total of 883 recommendations.We undertake a thematic analysis to identify 7 core ways to improve usability of APIs. We find that most of the recommendations focus on helping API developers to construct and structure their code and make it more usable and easier for programmers to understand. There is less focus, however, on documentation, writing requirements, code quality assessment and the impact of organizational software development practices. By tracing and analyzing paper ancestry, we map how this knowledge becomes validated and translated over time.We find evidence that less than a quarter of all API usability recommendations are empirically validated, and that recommendations specific to usable security APIs lag even further behind in this regard.

cs.CR↗
arXiv2021

The best laid plans or lack thereof: Security decision-making of different stakeholder groups

Cyber security requirements are influenced by the priorities and decisions of a range of stakeholders. Board members and CISOs determine strategic priorities. Managers have responsibility for resource allocation and project management. Legal professionals concern themselves with regulatory compliance. Little is understood about how the security decision-making approaches of these different stakeholders contrast, and if particular groups of stakeholders have a better appreciation of security requirements during decision-making. Are risk analysts better decision makers than CISOs? Do security experts exhibit more effective strategies than board members? This paper explores the effect that different experience and diversity of expertise has on the quality of a team's cyber security decision-making and whether teams with members from more varied backgrounds perform better than those with more focused, homogeneous skill sets. Using data from 208 sessions and 948 players of a tabletop game run in the wild by a major national organization over 16 months, we explore how choices are affected by player background (e.g.,~cyber security experts versus risk analysts, board-level decision makers versus technical experts) and different team make-ups (homogeneous teams of security experts versus various mixes). We find that no group of experts makes significantly better game decisions than anyone else, and that their biases lead them to not fully comprehend what they are defending or how the defenses work.

cs.CR↗
arXiv2021

"Do this! Do that!, And nothing will happen" Do specifications lead to securely stored passwords?

Does the act of writing a specification (how the code should behave) for a piece of security sensitive code lead to developers producing more secure code? We asked 138 developers to write a snippet of code to store a password: Half of them were asked to write down a specification of how the code should behave before writing the program, the other half were asked to write the code but without being prompted to write a specification first. We find that explicitly prompting developers to write a specification has a small positive effect on the security of password storage approaches implemented. However, developers often fail to store passwords securely, despite claiming to be confident and knowledgeable in their approaches, and despite considering an appropriate range of threats. We find a need for developer-centered usable mechanisms for telling developers how to store passwords: lists of what they must do are not working.

cs.CR↗