Magosanyi Arpad wrote:
> > [ Discussion of real MAC vs. implied MAC using facility/level deleted ]
>
> I have some problem with the above approach:
>
> -By my reading, facilities are connected with the source of the
> event to be logged, and have nothing to do with the security labels
> of either the object or the subject engaged in the operation. Think
> of auditing of FS or http access.
> -Do not forget that MAC labels have _two_ components: hierarchical security
> label and non-hierarchical categoriES. Even if we would agree with mapping HSL
> to priorities (which I do not), you won't have place for the NHC labels.
> -I think that the priority of an event is more connected to the type of
> that event than to the labels of either the subject or object playing.
> (I am more concerned with a buffer overrun attempt in my ftp proxy by a system
> low entity than a dir command by a system high one.)
> -Do we log the subject's or the object's security labels with the above
> attributes?
>
> So I guess we should talk about labels where we talk about the representation
> of the other things (source, destination, time, ...). And that is another wg,
> isn't it?
I agree that the ideal is a full MAC labeling/control system.
However, given the IETF's stance on interoperation with
existing syslog implementations (at the protocol and API
level), we can't do that (at least we can't do that in most
situations).
As for my ideas about how to map facility/priority
into a MAC label, I think there's some confusion.
My idea is to map the priority to the hierarchical
security label and the facility to the non-hierarchical
security label. Yes, there is some confusions as to
whether the facility is to be used for the source
of the log messages (LOG_MAIL) or for what
it's trying to do from a security standpoint (LOG_AUTH),
but I think that's pretty minor and can be worked out.
You seem to disagree with this, but your example
(FTP buffer overrun from a system-low process
vs. dir command in a system-high process) doesn't seem
a very good example. Assuming both came from an FTP
related process, both would likely have LOG_FTP as the
facility, so I don't know where the system-high and
system-low parts come from (the source OS may
track this stuff, but if it's not on the wire we don't care).
Now, if you follow typical syslog practice, the
attempted buffer overrun would be something like
LOG_WARNING while the dir command would
be LOG_INFO. So, regardless of what kind of
MAC labels are being used by the source OS,
we get our own syslog-ish labels of
LOG_FTP/LOG_WARNING for the buffer overflow
attempt and LOG_FTP/LOG_INFO for the dir command.
Now, if we treat the facility as the non-hierarchical label,
then we can say that only people with LOG_FTP reading
privilege can read either of these messages. Furthermore,
if we treat priority as the hierarchical label, then
people with LOG_INFO reading privilege could read
both messages, but people at the lower LOG_WARNING
privilege level could read the entry claiming the attempted
buffer overflow, but couldn't read then entry for the
dir command (which might reveal information about
the filesystem layout of the FTP server).
This looks like it works perfectly if you ask me.
I will try to clarify the point in the language, however.
> The other thing is the representation of the facility and priority fields.
> AFAIK we cannot forget them because they are parts of the protocol right now.
> I couldn't find a statement on them being arbitrary labels rather than a limit
ed
> set of things.
Yes, in the current protocol they are a limited set
of things. For the priority, that seems reasonable
because a hierarchical list is by nature a limited set of things.
For the facility, this definitely poses an issue. We can define
an expanded protocol that allows arbitrary labels for the
facility for implementation that know about the new
protocol/API. But, we need to interoperate with existing
syslog implementations, so we need to keep support
for the existing limited set of facilities too.
> And what about defining the minimum set of information a log should contain?
> (maybe I have just skipped that through?)
Doing a search for 'must' in the document
reveals the following as required information:
o Originating machine (not in the existing
syslog protocol)
o Message sequence information (not in the
existing syslog protocol)
o Originating program/sub-system (the log facility)
I suppose I ought to throw in requirements for
the log priority.
--
Chris Calabrese
Internet Infrastructure and Security
Merck-Medco Managed Care, L.L.C.
[EMAIL PROTECTED]
.
