lkml.org 
[lkml]   [2004]   [Aug]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: secure computing for 2.6.7
On Sun, Aug 01, 2004 at 04:55:47PM +0200, Bernd Eckenfels wrote:
> Personally I think it is better to keep that in the utsname.release. If you
> realy want to have an integer, then add it for easy parsing and allow it to
> have multiple parallel issuers:
>
> For example like:
>
> 2.6.9_XXX(linux26.3501,MM.123)

I think it's overkill to pollue the `uname -r` with that detail. The
`uname -r` is about the release version nothing else.

> where this has applied fix 3501 in the 2.6 branch and 123 according to
> vendor MM, so you do not need to understand vendors XXX schema. However I am

if all vendors uses different numbers (i.e. vendor MM.123) then I can as
well build the ugly database in function of the `uname -r`
vendorization, building a database of uname -r or a database of
MM/linux-26/whatever isn't going to be any different.

> not sure if you are willing to accept the fact, that backporters will then
> raise the level to a value you will only expect for more recent versions,
> i.e.:
>
> 2.6.9(linux26.3501)
> -> security bug1 is discoverd and fixed
> 2.6.10pre1(linux26.3502)
> -> security bug2 is discoverd and fixed
> -> features are added
> 2.6.10(linux26.3503)
>
> Now somebody decides to backport the bug1 fix:
>
> 2.6.9-2(linux26.3502)
>
> and the bug2 fix:
>
> 2.6.9-3(linux26.3503) <- is level 3503 but does not have all 2.6.10 features?!
>
> And it gets even more hairy: if only the bug2 fix is
> backported, how can an application state that it needs that (without
> impliciteley also reling on bug1 to be fixed)

note this isn't a build number (the features in 2.6.10 don't matter at
all, the only thing it matters is that all security bugs up to 3503 are
included). This would be kernel wide for 2.4, 2.2 and 2.6. If 2.6 has a
bug and 2.4 not, then 2.4 can bump the number without any other
modification. because this isn't a build number, there are very few
fixes that would require bumping the security_sequence number, so it's
not like we're going to ever see 3503 in our life. The last one that
would require bumping the sequence number was probably fnclex months
ago, previously there was mremap (mremap wasn't relevant for seccomp but
some app might want to know about it). the the only one relevant for
seccomp mode 1 was fnclex and the only previous one I can recall
relevant for seccomp was the mmx sniffing a few years ago.

If a vendor ships you a kernel with security_sequence 3502 but it misses
the _few_ needed bugfixes that are supposedly included in a kernel with
security sequence 3502, than such a vendor could as well ship you a
kernel with seccomp mode 1 doing nothing or if you prefer they could
ship a kernel with a bug in the tcp stack that gains root by sending an
escape sequence on the wire, you get the idea. Then you could just
prefer to change vendor and run a secure OS ;). I exclude that a vendor
could intentionally not want to backport all needed fixes that requires
bumping the sequence number. And if they don't want to ship a "secure"
kernel they've simply not to touch the value of their security_sequence
and everything will work securely, they can just delete the rejects on
the sequence number modifications. You will definitely get a reject if
you apply a fix that bumps the sequence number and you miss the previous
fix that bumped the sequence number, so it can't go unnoticed (and
vendors are required to check rejects while applying patches). If
everyone bumps the number with security fixes this would actually _help_
increasing security, since even people self compiling kernels would
notice they miss some bugfix as they get the reject.

If people don't like the idea no problem, as worse I can build a
vendor-tuned security database in function of `uname -r` but it'll be
less secure and it'll be less finegrined than it could. I just thought a
sequence_number could be useful to something more than just knowing when
I can run safely in seccomp mode. Or if you prefer I can rename it to
seccomp_security_sequence, this way it would need a change only once
every few years at most and none of the kernel developers will have to
care about it and I'll take care to update it myself when needed (i.e.
ideally never ;).
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 14:04    [W:0.322 / U:0.500 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site