linux-kernel - Re: Including STRTOK

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <469B83FD.8080409@murdoch.edu.au>
Date:	Mon, 16 Jul 2007 22:43:09 +0800
From:	"Z. Cliffe Schreuders" <c.schreuders@...doch.edu.au>
To:	casey@...aufler-ca.com
CC:	Jan Engelhardt <jengelh@...putergmbh.de>,
	linux-kernel@...r.kernel.org
Subject: Re: Including STRTOK_R in a LSM

Casey Schaufler wrote:
> --- "Z. Cliffe Schreuders" <c.schreuders@...doch.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.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/