Greg Williamson wrote:
[wretched top-posting -- begs forgiveness!]
KaiGai --
I have edited the first three sections (up to but not including "Architecture"),
> mostly cleaning up language but I did run into a few places where I am not
> sure if I got the proper meaning -- I flagged those in square brackets
(e.g.[...])
> and with your name. Feel free to change them, accept them, or confer back
with me
> about them.
Thanks for your efforts so much.
I'll confirm it tomorrow (in JST).
In particular, in the Security policy section you had:
TE rules use the third field in the security context. It is called type or
domain (for processes).
allow httpd_t sepgsql_ro_table_t : db_table {getattr select lock};
I thought that colons were used to split these fields, so the above line would
> have only 2 ? Perhaps after the httpd_t ?
It says the third field in the security policy, not a rule in the security
policy. Sorry, it might be introduced more carefully.
In the default security policy, web server process performs labeled as
"system_u:system_r:httpd_t:s0".
^^^^^^^
This rule is checked when web server process tries to access a table labeled
as "system_u:object_r:sepgsql_ro_table_t:s0", for example.
^^^^^^^^^^^^^^^^^^
The TE rule is defined between the pair of third field (which is called type
or domain) of security contexts.
# BTW, basically, the second field is used for RBAC rules, the fourth field
# is used for MLS rules. The first field is used to record who create the
# object.
Thanks,
I'd like to get some feedback from you (and any other readers) before I do more
... I need to go deal an invasion of the kitchen -- it is garbage collection
morning (early) and I just had a pretty young skunk and two raccoon kits in
rapid order and I have to clean up and secure the premises.
Regards!
G
----- Original Message ----
From: Greg Williamson <gwilliamso...@yahoo.com>
To: KaiGai Kohei <kai...@ak.jp.nec.com>; KaiGai Kohei <kai...@kaigai.gr.jp>
Cc: Sam Mason <s...@samason.me.uk>; pgsql-hackers@postgresql.org
Sent: Tuesday, July 28, 2009 1:20:29 AM
Subject: Re: [HACKERS] SE-PostgreSQL Specifications
Thanks for the updates.
I might suggest a couple of small changes:
a) a section that explains comments like "This is not supported in the initial
version" -- do you
mean in the first Beta release of SE-PostgreSQL, or not in the initial
release(s) for commitfests ?
If it is not supported why mention it ? If experienced users of SELinux expect
it, they might look for
an explanation as to why it is missing and when it might appear. I'm not sure
if postgres DB
hackers would care if is it is not to be included. How much do these compromise
the design,
and if so, are there specific plans for implementing them ?
b) something which explains the differences between SELinux and SEPostgreSQL on
the one
hand (for SE fans). You've done a good job of outlining the differences and
similarities with the
more standard ACL methods and that needs to be kept prominent so people with DB
experience
can see the differences.
I am all in favor of external links if you can find good explanation of
concepts elsewhere. This is a
very high level outline and so I'd be tempted to move all implementation
details to another page --
basically everything from ""Installation" on, with the exception of the
overview of the dump issues,
is (to my eye) a detail that doesn't need exposing (yet).
I'll send mail when I have a few paragraphs done so you can check it and see if
you approve.
Apologies for top-posting -- lame mailer.
Greg W.
----- Original Message ----
From: KaiGai Kohei <kai...@ak.jp.nec.com>
To: KaiGai Kohei <kai...@kaigai.gr.jp>
Cc: Sam Mason <s...@samason.me.uk>; pgsql-hackers@postgresql.org
Sent: Monday, July 27, 2009 11:57:32 PM
Subject: Re: [HACKERS] SE-PostgreSQL Specifications
I revised the SE-PostgreSQL Specifications:
http://wiki.postgresql.org/wiki/SEPostgreSQL_Draft
- Put several external link to introduce something too detail
for PostgreSQL documentations.
- Paid attention not to use undefined terminology, such as
"security context", "security policy" and "mandatory access
controls".
- Revised whole of the composition in the "Brief overview" section.
- Put an example of security policy rule.
- "SECURITY_LABEL" option was replaced by "SECURITY_CONTEXT" to
avoid meaningless confusion.
I believe it become better than previous revision.
Thanks,
KaiGai Kohei wrote:
Sam Mason wrote:
On Sun, Jul 26, 2009 at 12:27:12PM +0900, KaiGai Kohei wrote:
Indeed, the draft used the term of "security context" with minimum
introductions, but not enough friendliness for database folks.
The purpose of security context is an identifier of any subject and
object to describe them in the security policy. Because the security
policy is common for operating system, databases, x-window and others,
any managed database objects needs its security context.
Anyway, I need to introduce them in the security model section.
I'm coming to the conclusion that you really need to link to external
material here; there must be good (and canonical) definitions of these
things outside and because SE-PG isn't self contained I really think you
need to link to them.
This will be somewhat of a break from normal PG documentation because
so far everything has been self contained, it's chosen its own
interpretation of the SQL standard and it needs to document that. SE-PG
will be interacting with much more code from outside and showing which
parts of these are PG specific vs. which parts are common to all SELinux
seems important.
If you try to document *everything* you're going to be writing for years
and give the impression that everything is implemented in SE-PG. A
dividing line needs to be drawn between what is PG specific and what is
SELinux (why not SEL?).
It also seems to me reasonable suggestion.
However, a reasonable amount (which should be adjusted under discussions)
of description should be self-contained.
For example, "security context is a formatted short string" is not enough
to understand why it is necessary and what is the purpose.
As Robert suggested, a few example and definition of technical terms
will help database folks to understand what it is, even if self-contained
explanation is not comprehensive from viewpoint of security folks.
Thanks,
--
KaiGai Kohei <kai...@kaigai.gr.jp>
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
