Secure Computer Systems - Quizzes

SELinux extends standard Linux access control by offering the following additional mechanisms.

• A SELinux user id that is separate from the standard Linux user id.

• Mandatory access control.

• New access checks that are not performed in Linux.

• All of the above.

Security context in SELinux can be associated with

• only subjects/users.

• only objects.

• either with a user or objects owned by him/her but not both.

• both subjects and objects.

The following is not an example of what is included in an object's security context.

• Object's ACL.

• Object's type used for type enforcement.

• Object's user.

• Object's multi-level security range.

Type enforcement (TE) access rules in SELinux allow policies to be defined that can limit access to objects based on

• time of the request made by the requestor.

• operation of the object called by the requestor (e.g., read on a file).

• previously called operations by the requestor.

• all of the above.

Assume SELinux kernel includes MyLSM Linux security module (LSM). However, no functions implemented by MyLSM are called when a certain file is accessed. This could be due to the following reason(s).

• standard discretionary access check on the file request fails.

• the access vector check contains no permissions for the file.

• the policy database does not specify permissions for the file.

• the policy file specifies no access for the file.

The implementation of the Bell and La Padula model in SELinux allows

• only a single sensitivity level to be associated with a user/object.

• writes to be done only at the level of the user.

• reads to be done only at the level of the user.

• none of the above.

SELinux policy rules specify

• access checks.

• inheritance.

• overrides.

• all of the above.

Although users need to update their passwords, we want to limit their ability to update the password file only when they execute the password program. In SELinux this could be done by specifying

• a rule that allows transition to a new domain type by executing a program.

• an inheritance rule.

• an override rule.

• providing write access to the password file to all users.

In SELinux multi-level security model, effective and clearance levels can be specified for a user. It is true that

• effective level must be less or equal to clearance level.

• clearance level must be less or equal to effective level.

• effective and clearance levels must be the same.

• there is no relationship between effective and clearance levels.

Consider the following SELinux MLS policy.

mlsconstrain { dir file lnk_file chr_file blk_file sock_file fifo_file } { read getattr execute }

(( l1 dom l2 ) or

(( t1 == mlsfilereadtoclr ) and ( h1 dom l2 )) or

( t1 == mlsfileread ) or

( t2 == mlstrustedobject ));

If a user is making a request for a file with the above MLS policy has a clearance level that dominates file's level l2, access to the file will be granted when

• l1 is dominated by l2.

• h1 dominates l2.

• user type has mlsfileread attribute set.

• mlstrustedobject is not set for object type.