>From: Chris Debenham [mailto:[EMAIL PROTECTED]
>Sent: Tuesday, August 15, 2006 2:03 PM
>To: Thomson, David-P63356
>Cc: fvwm@fvwm.org
>Subject: Re: FVWM: FVWM for "government" system
>
>On Tue, 2006-08-15 at 15:12 -0400, Dan Espen wrote:
>> "Thomson, David-P63356" <[EMAIL PROTECTED]> writes:
>> > FVWM Developers,
>> >
>> > I was told I can only ask questions on here if I am sufficiently
vague
>> > about what we are doing. I work for a government contractor and we
are
>> > currently working on a contract for one of those 3-lettered
agencies to
>> > do something with PCs and I am in charge (at the moment) of the UI
>> > design. Suffice it to say that our final project will be used by
most
>> > every gov/mil agency at some point in the coming years. We did a
market
>> > survey of window managers for the UI a while back and actually have
>> > chosen FVWM. Enough said...
>> >
>> > Here's my hopefully simple task: learn enough about FVWM to modify
it
>> > to meet our needs. Seeing as I am still an amateur in modifying
WMs, I
>> > hope to pick all your brains, and maybe get a little help while
writing
>> > these changes. Having FVWM on many MANY systems in 3-letter
abbreviated
>> > organizations and "special operations" type organizations along
with
>> > getting your beloved FVWM to become pretty ubiquitous may be
motivating
>> > factors.
>> >
>> > Let me know if this is the place to ask questions and if any of you
are
>> > "willing and able".
>> >
>> > My first task involves SELinux security labels and per-window
>> > decoration.
>> >
>> > Dave
>
>Ooo, this will not be easy. The only way I can think about doing it is
>to create a module that is capable of checking what process a windowid
>is associated with, then checking the label of that process. The
output
>of this could be used to choose a decor.
>Although this is all a bit insecure since the link between the decor
and
>the label is fairly weak. To do this to a level that would be
>considered secure enough to keep labels seperate you'd also need to
>monitor the x clipboard to ensure no data is copied down a security
>level and much more bits.
>If you really need this you may want to look at the metacity that Sun
is
>using for their trusted solaris extensions (can't remember if they
>released it yet though) as it is label aware and can handle most of
this
>in a secure manner.
>
>Chris
Here's a potential way of solving this, please let me know what the
obviously missing piece is or if this is the wrong approach:
The fw_match_style_id code currently applies styles based on window
class, name, or resource. Add a new field to the FvwmWindow struct
called security_label and create a new line in that initial loop of
fw_match_style_id to also try to match the style_id to our new field
like so:
if (matchWildcards(SID_GET_NAME(s_id), fw->security_label) ==
TRUE)
{
Return True;
}
This is spoofable as any window with name, resource, or class equal to a
defined security_label will take on that style, but we'll worry about
that later.
The problem then becomes: when we initialize a new window, how do we
correctly set the new 'security_label' field? Well we want it to lookup
the selinux label of the file being opened. But, the window manager
doesn't know what file was opened and X Windows doesn't know anything
but the XID of the new window. My question is, is there a function to
lookup the socket associated with an XID? If there is (or one is
written) then we can use netstat to lookup the process ID of the
executable associated with that socket. Once we know the process ID we
can lookup the command line arguments in /proc/*process id*/cmdline.
Then we know which file was launched to create the current window. We
then lookup the selinux label of that file and store that label in our
newly created 'security_label' field for that window. Viola?!?
We can assume for our case that the file will ALWAYS be opened as a
command line argument and not from within an already launched app.
Thanks again guys for you help,
Dave
