fresh mac code report

Ilmar S. Habibulin ilmar at watson.org
Tue Jan 22 12:39:52 GMT 2002


On Mon, 21 Jan 2002, Brian F. Feldman wrote:

> "Ilmar S. Habibulin" <ilmar at watson.org> wrote:
> > Well, lets hack mtree. What's a problem. IMHO, mtree is one of the perfect
> > solutions, because it is one of (or the only) tool which is used to
> > controls integrity of filesystems and file attributes.
> How about adding "command" support for mtree, as a more generic way of
> approaching it?  I do like the idea of using mtree to install attributes,
> regardless.
I'm hardly imagine how to approach it. mtree files can be made
automatically or edited by hands. If we create file by hands, then there
is no problem. But if we use something automated, then how could mtree
know of what kind of commands it must use in order to get and then to set
something (extended file attributes). I'll think about it, but if you have
some thought, share them please.

> You should be able to access any proceedings, really, for free from Usenix.
> Are you perhaps looking for the 96 Security Symposium DTE paper?  You can
> get a copy of that at:
>
> http://www.usenix.org/publications/library/proceedings/sec96/walker.html
Yes, i have one, sorry. Maybe i tryed to access other documents, and
something mixed up in my head.

> If SSH were to actually attempt to support management of credentials above
> and beyond standard UNIX DAC, it would probably have to be rewritten first.
> The current SSH implementations are absolutely not conducive to this; and
> indeed, it's probably quite bogus of a design for the implementation to want
> to swap between different sets of credentials in the first place (not in the
> least because attempting to swap between MAC labels could easily be totally
> inappropriate for a given MAC system.
The problem with ssh is solved by hacking login/init to set and unset
appropriate label on terminal device. I've send my dirty hack to Robert.

> The startx model is somewhat different, and is on the order of:
> startx needs to:
>   execute xinit
>   xinit needs to:
>     read from /etc and /usr/X11R6
>     fork and execute /usr/X11R6/bin/X (or Xwrapper)
>     read (execute) $HOME/.xinitrc
In my case access is denied for xauth utility.

> Note that in this case, startx starts with just the user's credentials, and
> permissions needed by X are gained generally from a setuid flag on it or
> Xwrapper.  Also, fd 0, 1, and 2 are all inherited from the context of the
> initial startx executed and not modified, so will generally be the terminal
> device itself.
Ye, i know. I have no time right now to handle this, maybe later i'll try
to understand what the problem is. But enforce_fs=0 helps. ;-)



To Unsubscribe: send mail to majordomo at trustedbsd.org
with "unsubscribe trustedbsd-discuss" in the body of the message



More information about the trustedbsd-discuss mailing list