Including STRTOK_R in a LSM

Including STRTOK_R in a LSM

[Z. Cliffe Schreuders]

I am aware strtok was removed from the kernel in 2002. However strtok_r 
is more desirable than strsep as I do not want to know about 'blank 
fields' (2 consecutive delimiters). Is it acceptable to simply include 
the strtok_r code in my security module? or should I create a wrapper 
for strsep to ignore blanks?

Thanks,

Z. Cliffe Schreuders

Please cc me.

Re: Including STRTOK_R in a LSM

[Jan Engelhardt]

On Jul 16 2007 16:52, Z. Cliffe Schreuders wrote:
>
> I am aware strtok was removed from the kernel in 2002. However strtok_r is more
> desirable than strsep as I do not want to know about 'blank fields' (2
> consecutive delimiters). Is it acceptable to simply include the strtok_r code
> in my security module? or should I create a wrapper for strsep to ignore
> blanks?

12:16 ichi:/dev/shm > cat test.c 
#include <stdio.h>
#include <string.h>
int main(void)
{
        char x[] = "foo::bar";
        char *w = x;
        char *p;
        while ((p = strsep(&w, ":")) != NULL)
                printf("\"%s\"\n", p);
}
12:16 ichi:/dev/shm > ./a.out 
"foo"
""
"bar"


q.e.d.


	Jan
-- 

Re: Including STRTOK_R in a LSM

[Z. Cliffe Schreuders]

What I need is to ignore double delimiters such as (::). This can be 
done trivially with a string comparison to check for "\0". What I want 
to know is if it is ok to include the strtok_r code in my security 
module, or if strtok was removed for a very good reason. I am porting a 
lot of existing code which already uses strtok_r to a kernel security 
module.

Thanks,

Cliffe.

Jan Engelhardt wrote:
> On Jul 16 2007 16:52, Z. Cliffe Schreuders wrote:
>   
>> I am aware strtok was removed from the kernel in 2002. However strtok_r is more
>> desirable than strsep as I do not want to know about 'blank fields' (2
>> consecutive delimiters). Is it acceptable to simply include the strtok_r code
>> in my security module? or should I create a wrapper for strsep to ignore
>> blanks?
>>     
> 12:16 ichi:/dev/shm > cat test.c 
> #include <stdio.h>
> #include <string.h>
> int main(void)
> {
>         char x[] = "foo::bar";
>         char *w = x;
>         char *p;
>         while ((p = strsep(&w, ":")) != NULL)
>                 printf("\"%s\"\n", p);
> }
> 12:16 ichi:/dev/shm > ./a.out 
> "foo"
> ""
> "bar"
>
>
> q.e.d.
>
>
> 	Jan
>   

Re: Including STRTOK_R in a LSM

[Casey Schaufler]

--- "Z. Cliffe Schreuders" <c.schreuders@murdoch.edu.au> wrote:

> What I need is to ignore double delimiters such as (::). This can be 
> done trivially with a string comparison to check for "\0". What I want 
> to know is if it is ok to include the strtok_r code in my security 
> module, or if strtok was removed for a very good reason. I am porting a 
> lot of existing code which already uses strtok_r to a kernel security 
> module.

All over the Linux world little red flags are popping up.

Text processing of the sort that requires token parsing is rare
in the kinds of things the kernel is usually called upon to do.
You did mention, and someone else demonstrated, that there are
existing alternatives that you could adopt. Cluttering the kernel
with duplicate functionality is strongly discouraged.

As far as porting existing code into the kernel goes, be sure to
have a look at the official coding style before you show what you've
done to anyone. If you're porting "a lot" of code (Use SELinux as a
benchmark for an LSM. If you're bigger than that you have "a lot"
of code) you may also be putting too much into the kernel. Some
application programmers use programming methods that are not suited
to the kernel environment, so be careful that what you're doing and
the way you're doing it are appropriate to the kernel.

Best of luck.



Casey Schaufler
casey@schaufler-ca.com

Re: Including STRTOK_R in a LSM

[Z. Cliffe Schreuders]

Casey Schaufler wrote:
> --- "Z. Cliffe Schreuders" <c.schreuders@murdoch.edu.au> wrote:
>
>   
>> What I need is to ignore double delimiters such as (::). This can be 
>> done trivially with a string comparison to check for "\0". What I want 
>> to know is if it is ok to include the strtok_r code in my security 
>> module, or if strtok was removed for a very good reason. I am porting a 
>> lot of existing code which already uses strtok_r to a kernel security 
>> module.
>>     
>
> All over the Linux world little red flags are popping up.
>
> Text processing of the sort that requires token parsing is rare
> in the kinds of things the kernel is usually called upon to do.
> You did mention, and someone else demonstrated, that there are
> existing alternatives that you could adopt. Cluttering the kernel
> with duplicate functionality is strongly discouraged.
>   
Thanks Casey,

I plan to pass simple lines of policy from user-space into kernel 
functions which use this information to build the internal 
representation of policy.
I had started writing these functions in user-space (to save time :\) 
and stupidly did not check that strtok_r was available from within the 
kernel (I thought string.h would include it). Anyway, so now I have a 
rewrite on my hands (unless I just include the strtok_r code). All part 
of the learning process I guess.
> As far as porting existing code into the kernel goes, be sure to
> have a look at the official coding style before you show what you've
> done to anyone. 
Will do.
> If you're porting "a lot" of code (Use SELinux as a
> benchmark for an LSM. If you're bigger than that you have "a lot"
> of code) you may also be putting too much into the kernel. 
It is not a lot in comparison to SELinux.

Thanks,

Cliffe.

Getting the port numbers and IP address from struct socket

[Cliffe]

Hi,

This may be a simple question, but how do I determine the port numbers, 
and IP addresses from a (struct socket)socket?

I appreciate any advice. Thank you,

Cliffe.
-- 

Re: Getting the port numbers and IP address from struct socket

[Matthias Kaehlcke]

El Mon, Mar 16, 2009 at 10:03:31PM +0800 Cliffe ha dit:

> This may be a simple question, but how do I determine the port numbers,  
> and IP addresses from a (struct socket)socket?

i'm far from being a networking expert, so i might be plain
wrong. after having a look at the kernel sources i think it works in
the following way:

struct inet_sock *inet = inet_sk(socket->sk);

the data you are looking for are:

inet->saddr
inet->sport
inet->daddr
inet->dport

btw: for these kind of questions it is better to write to the
kernelnewbies list (kernelnewbies@nl.linux.org)

best regards

-- 
Matthias Kaehlcke
Embedded Linux Engineer
Barcelona

      Anyone who has never made a mistake has never tried anything new
                            (Albert Einstein)
                                                                 .''`.
    using free software / Debian GNU/Linux | http://debian.org  : :'  :
                                                                `. `'`
gpg --keyserver pgp.mit.edu --recv-keys 47D8E5D4                  `-