The reason why SEPostgreSQL use original userspace AVC

The reason why SEPostgreSQL use original userspace AVC

[KaiGai Kohei]

Hi,

This was one of the topics discussed on SELinux developer summit held on
last Friday.
I like to send the reason why I made a decision to implement SE-PostgreSQL
with original userspace AVC, for wider discussion.
(SE-PostgreSQL didn't use the userspace AVC provided by libselinux.)

There are two major reasons. The one is a performance gain. The other is
concurrency of invalidation.

Any comment and suggestion please.

[ performance gain ]

The biggest reason is originated from the way to associate a security context
for each tuple. As I mentioned, I modified the internal data structure of
tuples to add its security context. The field is a 4-byte length integer
variable (same as object id data type), not a string expression.
This value is associated with the contains of 'pg_selinux'.

'pg_selinux' is one of the system catalogs. System catalogs are special tables
which contains database meta information like definition of table, view, stored
procedure and so on.
'pg_selinux' has two column. One is 'oid' defined as object id type. It hold
a unique number within the table. The other is 'selcontext' defined as variable
length text type. It hold a security context in text expression.
So, we can refer the pg_selinux system catalog, when a text expression of security
context is required.
(e.g A case when 'security_context' is specified in SQL queries.)

The object id enables to identify a security context in text expression, so we
can also apply them as a key of userspace avc. I named it as psid (persistent
security id).

Using psid enables to be unnecessary to handle a text represented security context
in the most frequently path. When we have to make a decision whether the fetched
tuple is allowed or not, we can search the userspace avc with psid held by the tuple
as is.

In the userspace avc provided by libselinux. Its avc_has_perm() requires security_id_t
as arguments, but it means we have to translate security context from psid to text
representation in a decision making process.
No need to say, it make a bad effect to the performance of SE-PostgreSQL.

[ concurrency of invalidation ]

SE-PostgreSQL deploys its userspace avc on the shared memory region, and generates
a single policy state monitoring process to poll netlink socket at bootup time.
It enables to invalidate the userspace avc referred by all SE-PostgreSQL instances
concurrently.

If the userspace avc is deployed on the process local memory for each instance,
we need policy state monitoring threads for each instances and the invalidation
of userspace avc is not done concurrently.
At a moment, different policies may be applied between SE-PostgreSQL instances.

In addition, we will get a little performance improvement on startup time of instances.
If the userspace avc deployed on the shared memory region, it may contains several
access control rules before it is referred at first. It enables to reduce the number
of calling system-call.
And, it is not necessary to generate a policy state monitoring thread for each
SE-PostgreSQL instance.

Thanks,
-- 
KaiGai Kohei <kaigai@kaigai.gr.jp>

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: The reason why SEPostgreSQL use original userspace AVC

[Stephen Smalley]

On Mon, 2007-03-19 at 23:11 +0900, KaiGai Kohei wrote:
> Hi,
> 
> This was one of the topics discussed on SELinux developer summit held on
> last Friday.
> I like to send the reason why I made a decision to implement SE-PostgreSQL
> with original userspace AVC, for wider discussion.
> (SE-PostgreSQL didn't use the userspace AVC provided by libselinux.)
> 
> There are two major reasons. The one is a performance gain. The other is
> concurrency of invalidation.
> 
> Any comment and suggestion please.
> 
> [ performance gain ]
> 
> The biggest reason is originated from the way to associate a security context
> for each tuple. As I mentioned, I modified the internal data structure of
> tuples to add its security context. The field is a 4-byte length integer
> variable (same as object id data type), not a string expression.
> This value is associated with the contains of 'pg_selinux'.
> 
> 'pg_selinux' is one of the system catalogs. System catalogs are special tables
> which contains database meta information like definition of table, view, stored
> procedure and so on.
> 'pg_selinux' has two column. One is 'oid' defined as object id type. It hold
> a unique number within the table. The other is 'selcontext' defined as variable
> length text type. It hold a security context in text expression.
> So, we can refer the pg_selinux system catalog, when a text expression of security
> context is required.
> (e.g A case when 'security_context' is specified in SQL queries.)
> 
> The object id enables to identify a security context in text expression, so we
> can also apply them as a key of userspace avc. I named it as psid (persistent
> security id).
> 
> Using psid enables to be unnecessary to handle a text represented security context
> in the most frequently path. When we have to make a decision whether the fetched
> tuple is allowed or not, we can search the userspace avc with psid held by the tuple
> as is.
> 
> In the userspace avc provided by libselinux. Its avc_has_perm() requires security_id_t
> as arguments, but it means we have to translate security context from psid to text
> representation in a decision making process.
> No need to say, it make a bad effect to the performance of SE-PostgreSQL.

So I understand correctly, the underlying issue here is that you want
your userspace object manager to be able to generate its own SID mapping
(in your case, using these psids or object ids) rather than have the SID
mapping handled entirely within libselinux, so that you can have the ids
also represent something meaningful to the object manager for efficient
lookup.  It seems possible to have the libselinux userspace AVC export
interfaces to allow an object manager to optionally populate the
SID->context mapping itself using identifiers it selects.  Would that
address your concern?

> [ concurrency of invalidation ]
> 
> SE-PostgreSQL deploys its userspace avc on the shared memory region, and generates
> a single policy state monitoring process to poll netlink socket at bootup time.
> It enables to invalidate the userspace avc referred by all SE-PostgreSQL instances
> concurrently.
> 
> If the userspace avc is deployed on the process local memory for each instance,
> we need policy state monitoring threads for each instances and the invalidation
> of userspace avc is not done concurrently.
> At a moment, different policies may be applied between SE-PostgreSQL instances.
> 
> In addition, we will get a little performance improvement on startup time of instances.
> If the userspace avc deployed on the shared memory region, it may contains several
> access control rules before it is referred at first. It enables to reduce the number
> of calling system-call.
> And, it is not necessary to generate a policy state monitoring thread for each
> SE-PostgreSQL instance.

I'd be interested in seeing your userspace AVC implementation - is it
short enough that you can post it, or if not, point us to the specific
files in your repository?  I would tend to think that any gains you
might get from sharing a single AVC among multiple processes would tend
to be negated by 1) the locking required to make that safe (similar to
the locking support in the AVC for multi-threaded applications), and 2)
the affect on the cache of having multiple processes using it for
different access checks.  Also, IIUC, you don't need to have a separate
thread monitoring the netlink socket per se; the libselinux AVC can
check just its state on each avc_has_perm call in the non-threaded case.

-- 
Stephen Smalley
National Security Agency


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: The reason why SEPostgreSQL use original userspace AVC

[Stephen Smalley]

On Wed, 2007-03-21 at 08:38 -0400, Stephen Smalley wrote:
> On Mon, 2007-03-19 at 23:11 +0900, KaiGai Kohei wrote:
> > Hi,
> > 
> > This was one of the topics discussed on SELinux developer summit held on
> > last Friday.
> > I like to send the reason why I made a decision to implement SE-PostgreSQL
> > with original userspace AVC, for wider discussion.
> > (SE-PostgreSQL didn't use the userspace AVC provided by libselinux.)
> > 
> > There are two major reasons. The one is a performance gain. The other is
> > concurrency of invalidation.
> > 
> > Any comment and suggestion please.
> > 
> > [ performance gain ]
> > 
> > The biggest reason is originated from the way to associate a security context
> > for each tuple. As I mentioned, I modified the internal data structure of
> > tuples to add its security context. The field is a 4-byte length integer
> > variable (same as object id data type), not a string expression.
> > This value is associated with the contains of 'pg_selinux'.
> > 
> > 'pg_selinux' is one of the system catalogs. System catalogs are special tables
> > which contains database meta information like definition of table, view, stored
> > procedure and so on.
> > 'pg_selinux' has two column. One is 'oid' defined as object id type. It hold
> > a unique number within the table. The other is 'selcontext' defined as variable
> > length text type. It hold a security context in text expression.
> > So, we can refer the pg_selinux system catalog, when a text expression of security
> > context is required.
> > (e.g A case when 'security_context' is specified in SQL queries.)
> > 
> > The object id enables to identify a security context in text expression, so we
> > can also apply them as a key of userspace avc. I named it as psid (persistent
> > security id).
> > 
> > Using psid enables to be unnecessary to handle a text represented security context
> > in the most frequently path. When we have to make a decision whether the fetched
> > tuple is allowed or not, we can search the userspace avc with psid held by the tuple
> > as is.
> > 
> > In the userspace avc provided by libselinux. Its avc_has_perm() requires security_id_t
> > as arguments, but it means we have to translate security context from psid to text
> > representation in a decision making process.
> > No need to say, it make a bad effect to the performance of SE-PostgreSQL.
> 
> So I understand correctly, the underlying issue here is that you want
> your userspace object manager to be able to generate its own SID mapping
> (in your case, using these psids or object ids) rather than have the SID
> mapping handled entirely within libselinux, so that you can have the ids
> also represent something meaningful to the object manager for efficient
> lookup.  It seems possible to have the libselinux userspace AVC export
> interfaces to allow an object manager to optionally populate the
> SID->context mapping itself using identifiers it selects.  Would that
> address your concern?
> 
> > [ concurrency of invalidation ]
> > 
> > SE-PostgreSQL deploys its userspace avc on the shared memory region, and generates
> > a single policy state monitoring process to poll netlink socket at bootup time.
> > It enables to invalidate the userspace avc referred by all SE-PostgreSQL instances
> > concurrently.
> > 
> > If the userspace avc is deployed on the process local memory for each instance,
> > we need policy state monitoring threads for each instances and the invalidation
> > of userspace avc is not done concurrently.
> > At a moment, different policies may be applied between SE-PostgreSQL instances.
> > 
> > In addition, we will get a little performance improvement on startup time of instances.
> > If the userspace avc deployed on the shared memory region, it may contains several
> > access control rules before it is referred at first. It enables to reduce the number
> > of calling system-call.
> > And, it is not necessary to generate a policy state monitoring thread for each
> > SE-PostgreSQL instance.
> 
> I'd be interested in seeing your userspace AVC implementation - is it
> short enough that you can post it, or if not, point us to the specific
> files in your repository?  I would tend to think that any gains you
> might get from sharing a single AVC among multiple processes would tend
> to be negated by 1) the locking required to make that safe (similar to
> the locking support in the AVC for multi-threaded applications), and 2)
> the affect on the cache of having multiple processes using it for
> different access checks.  Also, IIUC, you don't need to have a separate
> thread monitoring the netlink socket per se; the libselinux AVC can
> check just its state on each avc_has_perm call in the non-threaded case.

Did you measure performance using both your own AVC vs. using the
libselinux one to see what the real impact was of these changes?

-- 
Stephen Smalley
National Security Agency


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: The reason why SEPostgreSQL use original userspace AVC

[KaiGai Kohei]

> Did you measure performance using both your own AVC vs. using the
> libselinux one to see what the real impact was of these changes?

No.
I considered that it was a obvious case.
At least, two psid_to_context() and two avc_context_to_sid() per
a avc_has_perm() will be necessary additionally.

Thanks,
-- 
KaiGai Kohei <kaigai@kaigai.gr.jp>

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: The reason why SEPostgreSQL use original userspace AVC

[KaiGai Kohei]

Stephen Smalley wrote:
> On Mon, 2007-03-19 at 23:11 +0900, KaiGai Kohei wrote:
>> Hi,
>>
>> This was one of the topics discussed on SELinux developer summit held on
>> last Friday.
>> I like to send the reason why I made a decision to implement SE-PostgreSQL
>> with original userspace AVC, for wider discussion.
>> (SE-PostgreSQL didn't use the userspace AVC provided by libselinux.)
>>
>> There are two major reasons. The one is a performance gain. The other is
>> concurrency of invalidation.
>>
>> Any comment and suggestion please.
>>
>> [ performance gain ]
>>
>> The biggest reason is originated from the way to associate a security context
>> for each tuple. As I mentioned, I modified the internal data structure of
>> tuples to add its security context. The field is a 4-byte length integer
>> variable (same as object id data type), not a string expression.
>> This value is associated with the contains of 'pg_selinux'.
>>
>> 'pg_selinux' is one of the system catalogs. System catalogs are special tables
>> which contains database meta information like definition of table, view, stored
>> procedure and so on.
>> 'pg_selinux' has two column. One is 'oid' defined as object id type. It hold
>> a unique number within the table. The other is 'selcontext' defined as variable
>> length text type. It hold a security context in text expression.
>> So, we can refer the pg_selinux system catalog, when a text expression of security
>> context is required.
>> (e.g A case when 'security_context' is specified in SQL queries.)
>>
>> The object id enables to identify a security context in text expression, so we
>> can also apply them as a key of userspace avc. I named it as psid (persistent
>> security id).
>>
>> Using psid enables to be unnecessary to handle a text represented security context
>> in the most frequently path. When we have to make a decision whether the fetched
>> tuple is allowed or not, we can search the userspace avc with psid held by the tuple
>> as is.
>>
>> In the userspace avc provided by libselinux. Its avc_has_perm() requires security_id_t
>> as arguments, but it means we have to translate security context from psid to text
>> representation in a decision making process.
>> No need to say, it make a bad effect to the performance of SE-PostgreSQL.
> 
> So I understand correctly, the underlying issue here is that you want
> your userspace object manager to be able to generate its own SID mapping
> (in your case, using these psids or object ids) rather than have the SID
> mapping handled entirely within libselinux, so that you can have the ids
> also represent something meaningful to the object manager for efficient
> lookup.  It seems possible to have the libselinux userspace AVC export
> interfaces to allow an object manager to optionally populate the
> SID->context mapping itself using identifiers it selects.  Would that
> address your concern?

Yes.
If we can use PSIDs as an alternatives of security_id_t, it seems to me
a good idea.

>> [ concurrency of invalidation ]
>>
>> SE-PostgreSQL deploys its userspace avc on the shared memory region, and generates
>> a single policy state monitoring process to poll netlink socket at bootup time.
>> It enables to invalidate the userspace avc referred by all SE-PostgreSQL instances
>> concurrently.
>>
>> If the userspace avc is deployed on the process local memory for each instance,
>> we need policy state monitoring threads for each instances and the invalidation
>> of userspace avc is not done concurrently.
>> At a moment, different policies may be applied between SE-PostgreSQL instances.
>>
>> In addition, we will get a little performance improvement on startup time of instances.
>> If the userspace avc deployed on the shared memory region, it may contains several
>> access control rules before it is referred at first. It enables to reduce the number
>> of calling system-call.
>> And, it is not necessary to generate a policy state monitoring thread for each
>> SE-PostgreSQL instance.
> 
> I'd be interested in seeing your userspace AVC implementation - is it
> short enough that you can post it, or if not, point us to the specific
> files in your repository?  I would tend to think that any gains you
> might get from sharing a single AVC among multiple processes would tend
> to be negated by 1) the locking required to make that safe (similar to
> the locking support in the AVC for multi-threaded applications), and 2)
> the affect on the cache of having multiple processes using it for
> different access checks. 

http://sepgsql.googlecode.com/svn/trunk/src/backend/security/sepgsqlCore.c
includes the implementation of userspace AVC.

It utilizes the shared memory management system in PostgreSQL.
sepgsqlShmemSize() is called to return the size of avc we need.
In sepgsql_avc_init(), ShmemInitStruct() is called to create/attach a shmem
segment.
If the shmem segment is newly generated, we initialize a lock variable and
the userspace avc deployed on the shmem segment.

sepgsql_avc_audit() is called to generate an audit message.

sepgsql_avc_permission_noaudit() is the core of the userspace avc.
It uses a light weight lock provided by PostgreSQL. In actually, it's a mutext
lock held on shmem segment.

sepgsqlMonitoringPolicyState() is the implementation of policy state monitoring
process. It is fork()'ed on bootup.

http://sepgsql.googlecode.com/svn/trunk/src/backend/security/sepgsqlPsid.c
provides translation between PSID and security contexts in text representation.

When we try to update/insert on a cell declared with PSID type, psid_in() is
called at first. It formalize the security context into raw format. Then, it
convert into PSID by looking up pg_selinux system catalog.
In finally, a security context we inputed with text representation is translated
into an integer value with 4-byte length.

> Also, IIUC, you don't need to have a separate
> thread monitoring the netlink socket per se; the libselinux AVC can
> check just its state on each avc_has_perm call in the non-threaded case.

The checks are done by recvfrom() with a netlink socket.
Because the userspace AVC is referred so frequently in SE-PostgreSQL,
I thought that checks on each avc_has_perm() will cause serious
performance degradation.

Thanks,
-- 
KaiGai Kohei <kaigai@kaigai.gr.jp>

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Kernel Panics, when start with amendments in SELInux Source Code

[JanuGerman]

hi Every one,


I have made a change to the security server of the
SELinux to see the files, that it accesses and print
their names. But when the kernel re-boots after
compilation, it panics and says that "some thing is
accessing directly the hardware" and keep on saying
this, until, i disable the selinux at boot time.

The code is as follows added to the
security_compute_av

const unsigned char *filepathp;
	char filepathbuf[512];	
	unsigned long count;
	filepathp = (const unsigned char *)
	    d_path(testfile->f_dentry, testfile->f_vfsmnt,
filepathbuf, 512);
	if (filepathp < 0) {
		filepathp = testfile->f_dentry->d_name.name;
		count = testfile->f_dentry->d_name.len + 1;
		if (count > 512)
			count = 512;
	} else {
		count = strlen(filepathp);
	}
	printk("Hi, this is the name of the file being
accessed %s \n",filepathp);
	return 0;


The testfile object is set within the
fs/nami.c:file_permission() into to a global variable,
which is then accessed by the services.c via
linux/fs.h.



The intention is to get the file information
associated with particular inodes. If some body can
help me in sorting out this, i will be very thankful.

Best,
MA



		
___________________________________________________________ 
The all-new Yahoo! Mail goes wherever you go - free your email address from your Internet provider. http://uk.docs.yahoo.com/nowyoucan.html

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Kernel Panics, when start with amendments in SELInux Source Code

[Stephen Smalley]

On Wed, 2007-03-21 at 17:54 +0000, JanuGerman wrote:
> I have made a change to the security server of the
> SELinux to see the files, that it accesses and print
> their names. But when the kernel re-boots after
> compilation, it panics and says that "some thing is
> accessing directly the hardware" and keep on saying
> this, until, i disable the selinux at boot time.
> 
> The code is as follows added to the
> security_compute_av
> 
> const unsigned char *filepathp;
> 	char filepathbuf[512];	
> 	unsigned long count;
> 	filepathp = (const unsigned char *)
> 	    d_path(testfile->f_dentry, testfile->f_vfsmnt,
> filepathbuf, 512);

What makes you think there is any file at all on every permission check?
Many permission checks are on non-file objects altogether.

> 	if (filepathp < 0) {

if (IS_ERR(filepathp)) {

> 		filepathp = testfile->f_dentry->d_name.name;
> 		count = testfile->f_dentry->d_name.len + 1;
> 		if (count > 512)
> 			count = 512;

What is count used for?

> 	} else {
> 		count = strlen(filepathp);
> 	}
> 	printk("Hi, this is the name of the file being
> accessed %s \n",filepathp);
> 	return 0;
> 
> 
> The testfile object is set within the
> fs/nami.c:file_permission() into to a global variable,
> which is then accessed by the services.c via
> linux/fs.h.

That's nice, except that:
a) file_permission() in fs/namei.c doesn't get called at all for
non-file checks,
b) file_permisison() in fs/namei.c doesn't even get called at all for
many file checks.
c) you need to provide locking on that global variable.

> The intention is to get the file information
> associated with particular inodes. If some body can
> help me in sorting out this, i will be very thankful.

SELinux avc auditing or the syscall auditing will happily provide you
with such information.  No need to add printk's to SELinux for it.

-- 
Stephen Smalley
National Security Agency


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Kernel Panics, when start with amendments in SELInux Source Code

[JanuGerman]

Thanks for the reply.

> What makes you think there is any file at all on
> every permission check?
> Many permission checks are on non-file objects
> altogether.
> 

it means, that a check has to be placed within the
security server, such that, if and only if, there is
an av rule of the form:

 "allow  subject_t object_t :file {Perm_Set}",

Only then to call this user defined function. That is
if  "tclass" parameter of the security_compute_av,
corresponds to object file, only then read the file. 
Am i right?, secondly what value of the "tclass"
corresponds to the file object in particular.

> What is count used for?

The actuall thing which i am doing at the moment is
that, whenever a specific "file object" comes in the
security server for permission decision, say a file
which contains sensitive data, I want to read that
file fully, within the security server. The purpose of
the count variable is two fold. It is actually used in
memcpy() for copying the file name into a dummy file
object. Secondly, it is used for reading from the data
from the file using:

 count (testfile ->f_op -> read) (testfile, (char
_user *) bufp, PAGE_SIZE, &offset)
....

> That's nice, except that:
> a) file_permission() in fs/namei.c doesn't get
> called at all for
> non-file checks,
> b) file_permisison() in fs/namei.c doesn't even get
> called at all for
> many file checks.
> c) you need to provide locking on that global
> variable.

If file_permission() in fs/namei.c is not involved in
some cases at all, how does fs/namei.c:permission() is
called. Could you kindly tell me the path, that how
Security Server can have access to the "struct file",
if the permission involves a specific "file object".
Actually, i want to read a particular file within the
security server.  

What i think, specific files can be identified through
this way:

Subject and Object TYPES can be identified through
attributes such that if there is a constraint
expression of the form e.g.

  (u1 = u2 and t2 = sensitivefile ...)

we can pin down the file TYPE associated with
"sensitivefile" attribute, and correspondingly, the
actual file, which is a sensitive file and should be
read. How to do this what i think: The structure
constraint_expr within the ss/constraint.h contains an
attribute called attr, which will then correspond to
sensitivefile in the
ss/services.c:constraint_expr_eval() in this
particular case. Am I right?


Thanks,
MA




> 
> > The intention is to get the file information
> > associated with particular inodes. If some body
> can
> > help me in sorting out this, i will be very
> thankful.
> 
> SELinux avc auditing or the syscall auditing will
> happily provide you
> with such information.  No need to add printk's to
> SELinux for it.
> 
> -- 
> Stephen Smalley
> National Security Agency
> 
> 
> --
> This message was distributed to subscribers of the
> selinux mailing list.
> If you no longer wish to subscribe, send mail to
> majordomo@tycho.nsa.gov with
> the words "unsubscribe selinux" without quotes as
> the message.
> 



		
___________________________________________________________ 
The all-new Yahoo! Mail goes wherever you go - free your email address from your Internet provider. http://uk.docs.yahoo.com/nowyoucan.html

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Kernel Panics, when start with amendments in SELInux Source Code

[Karl MacMillan]

On Wed, 2007-03-21 at 19:47 +0000, JanuGerman wrote:
> Thanks for the reply.

> > What is count used for?
> 
> The actuall thing which i am doing at the moment is
> that, whenever a specific "file object" comes in the
> security server for permission decision, say a file
> which contains sensitive data, I want to read that
> file fully, within the security server. The purpose of
> the count variable is two fold. It is actually used in
> memcpy() for copying the file name into a dummy file
> object. Secondly, it is used for reading from the data
> from the file using:
> 
>  count (testfile ->f_op -> read) (testfile, (char
> _user *) bufp, PAGE_SIZE, &offset)
> ....
> 

>From this description it sounds like you want to intercept access to
certain files and present a processed version of that file to processes
accessing it. You may want to explore doing this from userspace.

You can create a file type accessible only by a single domain and run a
process in that domain that provides access to the files through IPC. If
the access needs to be provided without modifying applications you could
LD_PRELOAD a library to intercept the relevant libc calls.

This will likely be more maintainable and simpler to achieve. Looking
for references to assured pipelines can give you some ideas about this
general approach.

Karl


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Kernel Panics, when start with amendments in SELInux Source Code

[JanuGerman]

Thanks for the reply.

> What makes you think there is any file at all on
> every permission check?
> Many permission checks are on non-file objects
> altogether.
> 

it means, that a check has to be placed within the
security server, such that, if and only if, there is
an av rule of the form:

 "allow  subject_t object_t :file {Perm_Set}",

Only then to call this user defined function. That is
if  "tclass" parameter of the security_compute_av,
corresponds to object file, only then read the file. 
Am i right?, secondly what value of the "tclass"
corresponds to the file object in particular.

> What is count used for?

The actuall thing which i am doing at the moment is
that, whenever a specific "file object" comes in the
security server for permission decision, say a file
which contains sensitive data, I want to read that
file fully, within the security server. The purpose of
the count variable is two fold. It is actually used in
memcpy() for copying the file name into a dummy file
object. Secondly, it is used for reading from the data
from the file using:

 count (testfile ->f_op -> read) (testfile, (char
_user *) bufp, PAGE_SIZE, &offset)
....

> That's nice, except that:
> a) file_permission() in fs/namei.c doesn't get
> called at all for
> non-file checks,
> b) file_permisison() in fs/namei.c doesn't even get
> called at all for
> many file checks.
> c) you need to provide locking on that global
> variable.

If file_permission() in fs/namei.c is not involved in
some cases at all, how does fs/namei.c:permission() is
called. Could you kindly tell me the path, that how
Security Server can have access to the "struct file",
if the permission involves a specific "file object".
Actually, i want to read a particular file within the
security server.  

What i think, specific files can be identified through
this way:

Subject and Object TYPES can be identified through
attributes such that if there is a constraint
expression of the form e.g.

  (u1 = u2 and t2 = sensitivefile ...)

we can pin down the file TYPE associated with
"sensitivefile" attribute, and correspondingly, the
actual file, which is a sensitive file and should be
read. How to do this what i think: The structure
constraint_expr within the ss/constraint.h contains an
attribute called attr, which will then correspond to
sensitivefile in the
ss/services.c:constraint_expr_eval() in this
particular case. Am I right?


Thanks,
MA




> 
> > The intention is to get the file information
> > associated with particular inodes. If some body
> can
> > help me in sorting out this, i will be very
> thankful.
> 
> SELinux avc auditing or the syscall auditing will
> happily provide you
> with such information.  No need to add printk's to
> SELinux for it.
> 
> -- 
> Stephen Smalley
> National Security Agency
> 
> 
> --
> This message was distributed to subscribers of the
> selinux mailing list.
> If you no longer wish to subscribe, send mail to
> majordomo@tycho.nsa.gov with
> the words "unsubscribe selinux" without quotes as
> the message.
> 



	
	
		
___________________________________________________________ 
New Yahoo! Mail is the ultimate force in competitive emailing. Find out more at the Yahoo! Mail Championships. Plus: play games and win prizes. 
http://uk.rd.yahoo.com/evt=44106/*http://mail.yahoo.net/uk 

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Kernel Panics, when start with amendments in SELInux Source Code

[Stephen Smalley]

On Wed, 2007-03-21 at 19:48 +0000, JanuGerman wrote:
> Thanks for the reply.
> 
> > What makes you think there is any file at all on
> > every permission check?
> > Many permission checks are on non-file objects
> > altogether.
> > 
> 
> it means, that a check has to be placed within the
> security server, such that, if and only if, there is
> an av rule of the form:
> 
>  "allow  subject_t object_t :file {Perm_Set}",
> 
> Only then to call this user defined function. That is
> if  "tclass" parameter of the security_compute_av,
> corresponds to object file, only then read the file. 
> Am i right?, secondly what value of the "tclass"
> corresponds to the file object in particular.

Please, spend some time reading the code (and a good book on kernel
development) first.

> 
> > What is count used for?
> 
> The actuall thing which i am doing at the moment is
> that, whenever a specific "file object" comes in the
> security server for permission decision, say a file
> which contains sensitive data, I want to read that
> file fully, within the security server. The purpose of
> the count variable is two fold. It is actually used in
> memcpy() for copying the file name into a dummy file
> object. Secondly, it is used for reading from the data
> from the file using:
> 
>  count (testfile ->f_op -> read) (testfile, (char
> _user *) bufp, PAGE_SIZE, &offset)

Wrong approach.  You need to measure the actual data used, not
separately read a private copy, and the security server should never
read from a file directly.

> If file_permission() in fs/namei.c is not involved in
> some cases at all, how does fs/namei.c:permission() is
> called.

Read the code and work your way through it.  It isn't that hard.

>  Could you kindly tell me the path, that how
> Security Server can have access to the "struct file",
> if the permission involves a specific "file object".
> Actually, i want to read a particular file within the
> security server.  

You don't want to do it that way.

> What i think, specific files can be identified through
> this way:
> 
> Subject and Object TYPES can be identified through
> attributes such that if there is a constraint
> expression of the form e.g.
> 
>   (u1 = u2 and t2 = sensitivefile ...)
> 
> we can pin down the file TYPE associated with
> "sensitivefile" attribute, and correspondingly, the
> actual file, which is a sensitive file and should be
> read. How to do this what i think: The structure
> constraint_expr within the ss/constraint.h contains an
> attribute called attr, which will then correspond to
> sensitivefile in the
> ss/services.c:constraint_expr_eval() in this
> particular case. Am I right?

Selecting files for measurement based on security label isn't a new
idea; go look at past discussions of integrity measurement on
linux-security-module and linux-kernel mailing lists and talk to the
people involved in such work.  There are certainly issues there, but you
should at least learn from what has already been tried.

-- 
Stephen Smalley
National Security Agency


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.