fresh mac code report

[Brian F. Feldman]

"Ilmar S. Habibulin" <ilmar at watson.org> wrote:
> 
> 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.

I was simply thinking along the lines that it's about as easy to type 
"setfmac foo/bar {}" as it is "mac=foo/bar", and because of this it may not 
be worth it specifically adding mac labeling support itself to mtree.

> > 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.

I don't understand; how do login and init factor into the operation of ssh?

> > 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.

What fmac are your files and pmac is X?  Have you tried adjusting the 
location of the XAUTHORITY file to, e.g., /tmp and verified it works?

> > 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. ;-)

You haven't had any problems with XFree86's ioctl calls on the terminal 
device, right?

-- 
 Brian Fundakowski Feldman           \  FreeBSD: The Power to Serve!  /
 green at FreeBSD.org                    `------------------------------'



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