Re: another volunteer
On Wed, May 09, 2001 at 11:57:45PM +0200, Alfonso De Gregorio wrote:
> In my opinion, the GNU/Linux Security SIG should address only
> the security issues ingrained in either the system interface
> or the environment described in LSB specifications.
> I should be out of the scope of this SIG to describe how:
> the developers of GNU/Linux distributions must implement commands
> and utilities in a "secure" and robust way (code auditing and
> developing are inevitably vendors tasks).
In the Discussion which led to the idea to form a security SIG
my focus was to guarantee GNU/Linux distributors freedom to make
there System as secure as possible.
Chapter 17 (FHS) is mainly written to avoid the situation that
a System is "to secure" to execute a LSB compliant app. You can
call that "protecting the interface".
Ruling out direct manipulation of user/group files in Chapter 16
guarantee the possibility for distributors to use more secure
authentication modules without breaking LSB compliance.
> However, since I have not searched yet the list archive for related
> threads, I am simingly missing some goals for this SIG.
I see these groups of tasks:
o Protect the LSB interface so that it does not implilcitly forces
a system to "deactivate his shields and cloak devices".
o Give security guidelines to application developers
o Give security guidelines to LSB compliant system developers.
I agree that these "guidelines" should not become part of the lsb spec
as a binding part. Let us concentrate on the spec now and if we did
all the necessary wording to protect the Interface.
Anything else should not block the spec.
> Here it is a partial list of issues that may or may not be addressed
> by the Security SIG. It would be nice add to it other issues and
> group its items in a "must be addressed" and "must not be addressed"
> lists.
I added my !comments
Item |Relevant Spec. Sections| Comments
---------------------------------|-----------------------|----------
libc functions prone to security | 10.1 | !SLIP
problems | |
---------------------------------|-----------------------|----------
cryptographic hash functions | chapter 13 | !SLIP
supported for packages verificati| |
---------------------------------|-----------------------|----------
security issues in dynamic linkin| chapter 7 | !insert a warning
that the program
interpreter will
eventually ignore
some of the LD_*
environ. var.
[I will do that]
-----------------------------------|----------------------|----------
/dev/{u,}random behavior and how | | more
seeds are handled at system | |generally:
initialization | | PRNG
!SLIP
-----------------------------------|----------------------|----------
security and environment variables | |!SLIP
(eg. IFS, PATH, TMPDIR, etc...) | |
-----------------------------------|----------------------|----------
Posix.1e (POSIX.6) | |!what is to do ?
-----------------------------------|----------------------|----------
PAM or more generally | |!SLIP
authentication mechanisms | |
-----------------------------------|----------------------|----------
users & groups | Chapter 16 | alreay
| | present
| |----------
| | DAC?
| | ! ????
-----------------------------------|----------------------|----------
ownerships and permissions | 17.2 | already
| | present
-----------------------------------|----------------------|----------
Internation Kernel Patch and its | | !we do not
support | | ! want apps
! to touch the
! kernel
-----------------------------------|----------------------|----------
--
______ ___
/ ___/__/ / Caldera (Deutschland) GmbH
/ /_/ _ / /__ Naegelsbachstr. 49c, 91052 Erlangen, Germany
/_____/_/ /____/ software developer / lsb project
==== /____/ ===== Dipl. Inf. Johannes Poehlmann, mail: jhp@caldera.de
Caldera OpenLinux phone: ++49 9131 7192 335, fax: ++49 9131 7192 399
Reply to: