Friday, November 25, 2005

LUC - what is Least-privileged User Account?

Today's Tip is related to "Access control and security":

Most of us who test applications on windows platform use an account that has administrative privileges on the machine from where they are running the tests. This means that the application that runs has access to "everything on the computer". Try running the application that you are testing - by logging in to windows as non admin account. You might see serious issues - application may not launch, it may give weird messages and host of other issues that you would never notice if you are not working with an account that has admin privileges on the machine.

Why it is important to Test (Sometimes in a test cycle) by logging as non-admin account?

As golden rule of access control and security - a program should mandate an account privilege that is just sufficient to execute the required functionalities nothing more. Developers while developing typically work on admin account , develop code that assumes admin level of access and put that code on a production box. But the moment some body with non admin account uses the application - some part of the application may break. A Tester should explore the ways in which the application is using the access model and investigate where things look suspicious.

What's the problem with a developer having administrator privileges on her local machine?

The problem is that developing software in that kind of environment makes possible Least-Privileged User account (LUA) bugs that can arise in the earliest stages of a project and grow and compound from there.

Following as an excerpt is from the book Computer Security: Art and Science, written by Matt Bishop, ISBN 0-201-44099-7, copyright 2003.

Definition 13-1. The Principle of Least Privilege states that a subject should be given only those privileges needed for it to complete its task.If a subject does not need an access right, the subject should not have that right. Further, the function of the subject (as opposed to its identity) should control the assignment of rights. If a specific action requires that a subject's access rights be augmented, those extra rights should be relinquished immediately upon completion of the action.
This is the analogue of the "need to know" rule: if the subject does not need access to an object to perform its task, it should not have the right to access that object. More precisely, if a subject needs to append to an object, but not to alter the information already contained in the object, it should be given append rights and not write rights.In practice, most systems do not have the needed granularity of privileges and permissions to apply this principle precisely. The designers of security mechanisms then apply this principle as best they can. In such systems, the consequences of security problems are often more severe than the consequences on systems which adhere to this principle.This principle requires that processes should be confined to as small a protection domain as possible.

Read this article on Least Privilege Access http://www.windowsecurity.com/articles/Implementing-Principle-Least-Privilege.html and this https://buildsecurityin.us-cert.gov/portal/article/knowledge/principles/least-privilege.xml

Try your LUC (luck?) next time by logginng in with the user not having the admin persimission on and see if you can notice something suspecious. Don't forget to send me a mail about the bug that you caught ...

Shrini

No comments: