linux-kernel - Re: [PATCH 3/5] v2 seccomp_filters: Enable ftrace-based system call filtering

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 for Android: free password hash cracker in your pocket

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

Date:	Thu, 9 Jun 2011 09:00:32 +0000 (UTC)
From:	Sven Anders <anders@...uras.de>
To:	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 3/5] v2 seccomp_filters: Enable ftrace-based system call filtering

Ingo Molnar <mingo <at> elte.hu> writes:

> <flame>
> 
> IMHO the key design mistake of LSM is that it detaches security 
> policy from applications: you need to be admin to load policies, you 
> need to be root to use/configure an LSM. Dammit, you need to be root 
> to add labels to files!
> 
> This not only makes the LSM policies distro specific (and needlessly 
> forked and detached from real security), but also gives the message 
> that:
> 
>  'to ensure your security you need to be privileged'
> 
> which is the anti-concept of good security IMO.
> 
> [....]
> </flame>
> 
> Thanks,
> 	Ingo

Hello!
An incomplete idea I had some time ago:

Couldn't the security information (like the selinux profiles) be
part of the binaries?

Each source package should deliver it's own security information
and this should be better than adding it later, because the 
developer of the program knows, what his program should be allowed
to do. Moreover, if the developer changes something, he can/must
add the security information altogether.

Of course these information has to be signed in some way to
avoid tampering.

Just an idea...

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