Re: User space API definition

sdsat_private

On Mon, 2003-08-18 at 06:22, Magosányi Árpád wrote:
> Actually I think that the libselinux API interface is
> generic enough to use, only the sid should be an opaque
> value which references the security attributes maintained
> by all module for a given subject/object. And of course the
> sid_to_context and context_to_sid calls should be able
> to handle the string representation for all of the attrs
> of all modules.

You must be looking at the old libsecure interface, prior to the
overhaul of the SELinux API for mainline 2.5/6.  SIDs are no longer
exported to userspace by the newer SELinux kernel API, nor by
libselinux.  Look again.

> I propose the following deviances from that API:
> -functions to get only the security attributes of the
>  subject/object (like a stat version which do not care
>  about getting struct stat)

In libselinux, this would be getfilecon for files (and naturally
lgetfilecon and fgetfilecon) and getpidcon for processes.

> -convenience functions with text representation of the
>  attrs

The SELinux security contexts are already a text representation.

> -the pam-like approach of Richard
> -have a more generic interface instead of security_compute_av
> 	The problem here that the access vectors are highly
> 	different in all modules, and we also need to ask for
> 	generic operations, like read and write (not read(2)
> 	or write(2)). Maybe an interface like
> 	decide(operation_t operation, sid object, sid subject)
> 	would be better.

The security_compute_av interface was carefully designed to support many
different security policy models, while also supporting efficient
computation of a set of related access decisions at one time when
possible.  Access vector interpretation is already based on security
class, so it isn't difficult to conceive of interpreting them based on
security class and security module.

But I'm not sure what value would be added by such a change.  The
SELinux API is already sufficiently generic to support MAC security
modules, and you can't provide a sane API for arbitrary security
modules.

-- 
Stephen Smalley <sdsat_private>
National Security Agency

_______________________________________________
linux-security-module mailing list
linux-security-moduleat_private
http://mail.wirex.com/mailman/listinfo/linux-security-module