linux-kernel - Re: [TOMOYO #12 (2.6.28-rc2-mm1) 05/11] Memory and pathname management functions.

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]

Date:	Tue, 11 Nov 2008 16:32:21 +0900
From:	Kentaro Takeda <takedakn@...data.co.jp>
To:	akpm@...ux-foundation.org
CC:	haradats@...data.co.jp, linux-security-module@...r.kernel.org,
	linux-kernel@...r.kernel.org, penguin-kernel@...ove.SAKURA.ne.jp
Subject: Re: [TOMOYO #12 (2.6.28-rc2-mm1) 05/11] Memory and pathname management
 functions.

Andrew Morton wrote:
>> Are you saying "make the callers of tmy_alloc() tolerable with
>> uninitialized memory"?
> 
> Well.  That would be a desirable objective.  I can understand the
> reasons for taking the easy way out.  Given that Tomoyo doesn't seem to
> ever free memory again, one hopes that this function doesn't get called
> a lot, so the performance impact of zeroing out all that memory should
> be negligible.
> 
> I think.  Maybe I misinterpreted tmy_alloc(), and perhaps it _is_
> called frequently?
It is called whenever open() / mkdir() / unlink() etc. are called,
but not when read() / write() are called.
Frequency of open() / mkdir() / unlink() etc. are much lower than frequency of
read() / write().
Main cost of pathname based access control is strcmp()ing (or even regexp()ing)
over the list of strings, therefore zeroing buffer for pathname is relatively
negligible.

>>>> Creating pseudo files for each variables is fine, though I don't see
>>>> advantage by changing from
>>>> "echo Shared: 16777216 > /sys/kernel/security/tomoyo/meminfo" to
>>>> "echo 16777216 > /sys/kernel/security/tomoyo/quota/shared_memory".
>>> Well for starters, the existing interface is ugly as sin and will make
>>> kernel developers unhappy.
>>>
>>> There is a pretty strict one-value-per-file rule in sysfs files, and
>>> "multiple tagged values in one file" violates that a lot.
>> /sys/kernel/security/ is not sysfs but securityfs.
>> Does "one-value-per-file rule" also apply to securityfs?
> 
> It should apply.  It's not so much a matter of rules and regulations. 
> One needs to look at the underlying _reasons_ why those rules came
> about.  We got ourselves into a sticky mess with procfs with all sorts
> of ad-hoc data presentation and input formatting.  It's inconsistent,
> complex, makes tool writing harder, etc.
> 
> So we recognised our mistakes and when sysfs (otherwise known as procfs
> V2 :)) came about we decided that sysfs files should not make the same
> mistakes.
> 
> So, logically, that thinking should apply to all new pseudo-fs files. 
> Even, in fact, ones which are in /proc!
Well, regarding memory usage, it is easy to follow "one-value-per-file rule".
But regarding policy information (which is managed as lists),
"one-value-per-file rule" is not suitable. I think none of SELinux, SMACK,
AppArmor, TOMOYO create "one pseudo file for one value".
This /sys/kernel/security/tomoyo/ interface is used by only TOMOYO's management
programs, and not by generic programs.

Regards,

--
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/