Results 1 -
3 of
3
Towards Supporting Users in Assessing the Risk in Privilege Elevation
, 2011
"... To better protect users from security incidents, the principle of least privilege (PLP) requires that users and programs be granted the most restrictive set of privileges possible to perform the required tasks. The low-privileged user accounts (LUA) and privilege elevation prompts are two practical ..."
Abstract
-
Cited by 2 (0 self)
- Add to MetaCart
(Show Context)
To better protect users from security incidents, the principle of least privilege (PLP) requires that users and programs be granted the most restrictive set of privileges possible to perform the required tasks. The low-privileged user accounts (LUA) and privilege elevation prompts are two practical implementations of PLP in the main-stream operating systems. However, there is anecdotal evidence suggesting that users do not employ these implementations correctly. Our research goal was to understand users ’ challenges and behavior in using these mechanisms and improve them so that average users of personal computers can follow the PLP correctly. For this purpose, we conducted a user study and contextual interviews to inves-tigate the understanding, behavior, and challenges users face when working with user accounts and the privilege elevation prompts (called User Account Control (UAC) prompts) in Windows Vista and 7. We found that 69 % of participants did not use and respond correctly to UAC prompts. Also, all our 45 participants used an admin user account, and 91 % were not aware of the benefits of low-privileged
A Practical Hardware-Assisted Approach to Customize Trusted Boot for Mobile Devices
"... Abstract. Current efforts to increase the security of the boot sequence for mobile devices fall into two main categories: (i) secure boot: where each stage in the boot sequence is evaluated, aborting the boot process if a non expected component attempts to be loaded; and (ii) trusted boot: where a ..."
Abstract
- Add to MetaCart
(Show Context)
Abstract. Current efforts to increase the security of the boot sequence for mobile devices fall into two main categories: (i) secure boot: where each stage in the boot sequence is evaluated, aborting the boot process if a non expected component attempts to be loaded; and (ii) trusted boot: where a log is maintained with the components that have been loaded in the boot process for later audit. The first approach is often criticized for locking down devices, thus reducing users' freedom to choose software. The second lacks the mechanisms to enforce any form of run-time verification. In this paper, we present the architecture for a two-phase boot verification that addresses these shortcomings. In the first phase, at boot-time the integrity of the bootloader and OS images are verified and logged; in the second phase, at run-time applications can check the boot traces and verify that the running software satisfies their security requirements. This is a first step towards supporting usage control primitives for running applications. Our approach relies on off-the-shelf secure hardware that is available in a multitude of mobile devices: ARM TrustZone as a Trusted Execution Environment, and Secure Element as a tamper-resistant unit.
System Security, Platform Security and Usability ∗ [Extended Abstract]
"... Scalable trusted computing seeks to apply and extend the fundamental technologies of trusted computing to large-scale systems. To provide the functionality demanded by users, bootstrapping a trusted platform is but the first of many steps in a complex, evolving mesh of components. The bigger picture ..."
Abstract
- Add to MetaCart
(Show Context)
Scalable trusted computing seeks to apply and extend the fundamental technologies of trusted computing to large-scale systems. To provide the functionality demanded by users, bootstrapping a trusted platform is but the first of many steps in a complex, evolving mesh of components. The bigger picture involves building up many additional layers to allow computing and communication across large-scale systems, while delivering a system retaining some hint of the original trust goal. Not to be lost in the shuffle is the most important element: the system’s human users. Unlike 40 years ago, they cannot all be assumed to be computer experts, under the employ of government agencies which provide rigorous and regular training, always on tightly controlled hardware and software platforms. It seems obvious that the design of scalable trusted computing systems necessarily must involve, as an immutable design constraint, realistic expectations of the actions and capabilities of normal human users. Experience shows otherwise. The security community does not have a strong track record of learning from user studies, nor of acknowledging that it is generally impossible to predict the actions of ordinary users other than by observing (e.g., through user experience studies) the actions such users actually take in the precise target conditions. We assert that because the design of scalable trusted computing systems spans the full spectrum from hardware to software to human users, experts in all these areas are essential to the end-goal of scalable trusted computing.
