A levelez�m azt hiszi, hogy Chris Calabrese a k�vetkez�eket �rta:
> I agree that the ideal is a full MAC labeling/control system.
We still can't understand each other. Maybe here is the point.
Do you talk about the labels of the log source, not of the labels
of objects subjects engaged in the event?
In this case you need an encapsulation protocol for the labels.
I don't know about one, but it is an issue which sould be addressed
sooner or more sooner, but not in this WG.
Communicating the labels with the encapsulation based on source IP/
facility/priority/whatewer is another issue, just like an API for such
a thing.
>
> 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).
Than don't do that. It's SEP (yeah, I want to talk with that Someone Else).
>
> 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
The problem is that we can have more non-hierarchical categories.
Not one.
> 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
Well, because we were talking about orthogonal things.
> 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.
Not, if you ask me. They are perfectly unrelated things, and the
fac/pri notion just cannot represent the labels. (Well, anything can
represent anithing, given the size of the key space, but see your
expanded protocol, which is a nuisance from the KISS standpoint.
>
> 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.
What if we accept arbitrary labels within those '<>' in the protocol.
The old implementation than can send to the new one. I think it is
an interoperative enough state, because the interoperativity/unupgradevity:)
problem exists with the end systems, not the log analizer systems.
The interoperability stance is a very binding one in your reading.
Look at the pals out there implementing those fancy and useful
implementations: they are all having an interoperative modus
operandi, but also they all designed a new protocol. It is not
for nothing. You can't be interoperative if you want to address
all of the issues of logging.
------------------------------------------------------------
!I think we should (?) mandate the current protocol as a must,
!(if IETF says so)
!but design another protocol which addresses all the issues
!and modular enough so it is not necessary to implement all the
!details for a modest ineroperability. If we do not do that,
!we will have a jungle of incompatible logging protocols, with
!only the plain old unusable logging protocol as the common subset.
!we can try to address issues on the ground of the current protocol,
!but only those issues which can be adressed in that way.
------------------------------------------------------------------
>
> > 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.
Is enumerating them in one place once more too much redundancy?
--
GNU GPL: csak tiszta forr�sb�l
