Andrew, * Andrew Sullivan (a...@crankycanuck.ca) wrote: > Throwing an error would entail a side-channel leak that would not be > acceptable to the security community, I bet. That said, I have > reservations, along the lines of Peter E's, that the early > design-level objections to the approach were never answered. I > certainly never got any real answer to questions I asked, for what > it's worth.
I've added Joshua Brindle (hope that's alright, Josh), since I'm not sure
if he's trying to follow this whole 'release planning' thread and your
concerns are regarding SE-PostgreSQL. I hope he can help to address
them (below).
> I will note that I tried to have a look at the literature on this
> topic. As I started to read, it became obvious that it was copious,
> but pretty well-determined. What bothered me most about the answers I
> got was that there never seemed to be an answer to "please outline the
> design principles" except for "it's what SE-Linux does". The OS-level
> control rules seemed to me to be totally foreign to the database
> world, precisely because ACID is a problem in databases in a way it
> isn't for filesystems under the traditional UNIX model. I formed the
> impression -- only an impression, mind, that there was a poor fit
> between SE-Linux and database systems, and that the proponents had
> decided that enough caulk (in the form of "don't do that") would seal
> the gap.
>
> I haven't (obviously) been paying much attention to this topic since,
> but I detect something of the same sort of response in the recent
> discussion. Maybe the goal isn't explicit enough. If the goal is
> compliance with some set of well-defined tests, what are they? If the
> goal is buzzword compliance, what are the tests of that (to the extent
> there ever are some)? If the goal is just "security enhancement", I
> confess that I am still unable to understand the definitions of
> "security" and "enhancement" such that I think we have some
> operationalization of what the patch is supposed to provide.
>
> I know there are people who think this is cool. I guess, if I were
> running the circus, I'd want to know what's cool about it, and why.
> Then maybe the project would be in a position to understand whether
> that kind of cool is the way it wants to be. But without a clear
> problem statement, and a roadmap of how the patches solve the problem,
> I'm at a loss. And last I checked (which was, admittedly, not today),
> the project pages didn't have that information.
Thanks,
Stephen
signature.asc
Description: Digital signature
