Re: 1.2.0-pre2 - first tests


From: Stanislav Ievlev <inger@altlinux.ru>
Subject: Re: 1.2.0-pre2 - first tests
Date: Mon, 29 Oct 2001 14:16:09 +0300

Next Article (by Author): Re: NSA - Spook Linux Stephen
Previous Article (by Author): Re: /etc protection Stanislav Ievlev
Top of Thread: 1.2.0-pre2 - first tests Stanislav Ievlev
Articles sorted by: [Date] [Author] [Subject]


--------------000605030803050009020406
Content-Type: text/plain; charset=KOI8-R; format=flowed
Content-Transfer-Encoding: 7bit

Amon Ott wrote:

>On Monday 29 October 2001 11:01, Stanislav Ievlev wrote:
>
>>I've just seen latest RSBAC. It's very interesting, but I have some
>>questions:
>>
>>1. Could you change usage messages for all utilites.
>>   We have are a new "module name" parameter for the utils now. If I
>>want to change some parameter, I don't know which module name I will
>>have to use for it. It's         will be good to see both parameters and
>>modules in usage screen ;)
>>
>
>Planned anyway. Tip: leaving it out will almost always do for now, though 
>that might disappear later...
>
>>2. Symlink redirection is very interesting, but it will be better to
>>resolve names like "<symlink>/<uid>" and not "<symlink><uid>". It's not
>>a good idea to have one             thousand directories (/tmp0,/tmp1
>>... /tmp500,...) under root dir.
>>
>
>The uid is added to the contents of the symlink, not the symlink name itself.
>
>Just make a link like suggested in kernel config help, and you end up in a 
>dir with all subdirs:
>cd / && mkdir /tmpdir/ && ln -s tmpdir/tmp tmp
>
>>Symlink redirection is a "light"
>>redirection, because I still can see all directories. What do you think
>>        about "hard" redirection for directories like I made for
>>RC-redirection  (in the Castle Beta3) ? ( RC-redirection is now ready
>>for intergation, because we have a new             "redirection" flag in
>>attributes).
>>
>
>I chose the symlink solution, because every user can always see where access 
>will go to. However, you can simply restrict all rights to /tmpdir to SEARCH, 
>and explicitly add rights for the subdir, if you do not want people to see 
>all of them.
>
>>3. What do you think about "soft mode" for separate modules?
>>
>
>Interesting, but too much work for now - all administration decisions would 
>have to be reworked. What would we really need it for?
>
Yes. Administrators who want to use Castle with RSBAC want it. They need 
it to test RSBAC configurations on remote machines.

>
>
>Amon.
>--
>http://www.rsbac.org
>-
>To unsubscribe from the rsbac list, send a mail to
>majordomo@rsbac.org with
>unsubscribe rsbac
>as single line in the body.
>



--------------000605030803050009020406
Content-Type: text/html; charset=KOI8-R
Content-Transfer-Encoding: 7bit

<html>
<head>
</head>
<body>
Amon Ott wrote:<br>
<blockquote type="cite" cite="mid:01102912352504.01063@marvin">
  <pre wrap="">On Monday 29 October 2001 11:01, Stanislav Ievlev wrote:<br></pre>
  <blockquote type="cite">
    <pre wrap="">I've just seen latest RSBAC. It's very interesting, but I have some<br>questions:<br><br>1. Could you change usage messages for all utilites.<br>   We have are a new "module name" parameter for the utils now. If I<br>want to change some parameter, I don't know which module name I will<br>have to use for it. It's         will be good to see both parameters and<br>modules in usage screen ;)<br></pre>
    </blockquote>
    <pre wrap=""><!----><br>Planned anyway. Tip: leaving it out will almost always do for now, though <br>that might disappear later...<br><br></pre>
    <blockquote type="cite">
      <pre wrap="">2. Symlink redirection is very interesting, but it will be better to<br>resolve names like "&lt;symlink&gt;/&lt;uid&gt;" and not "&lt;symlink&gt;&lt;uid&gt;". It's not<br>a good idea to have one             thousand directories (/tmp0,/tmp1<br>... /tmp500,...) under root dir.<br></pre>
      </blockquote>
      <pre wrap=""><!----><br>The uid is added to the contents of the symlink, not the symlink name itself.<br><br>Just make a link like suggested in kernel config help, and you end up in a <br>dir with all subdirs:<br>cd / &amp;&amp; mkdir /tmpdir/ &amp;&amp; ln -s tmpdir/tmp tmp<br><br></pre>
      <blockquote type="cite">
        <pre wrap="">Symlink redirection is a "light"<br>redirection, because I still can see all directories. What do you think<br>        about "hard" redirection for directories like I made for<br>RC-redirection  (in the Castle Beta3) ? ( RC-redirection is now ready<br>for intergation, because we have a new             "redirection" flag in<br>attributes).<br></pre>
        </blockquote>
        <pre wrap=""><!----><br>I chose the symlink solution, because every user can always see where access <br>will go to. However, you can simply restrict all rights to /tmpdir to SEARCH, <br>and explicitly add rights for the subdir, if you do not want people to see <br>all of them.<br><br></pre>
        <blockquote type="cite">
          <pre wrap="">3. What do you think about "soft mode" for separate modules?<br></pre>
          </blockquote>
          <pre wrap=""><!----><br>Interesting, but too much work for now - all administration decisions would <br>have to be reworked. What would we really need it for?</pre>
          </blockquote>
Yes. Administrators who want to use Castle with RSBAC want it. They need
it to test RSBAC configurations on remote machines.<br>
          <blockquote type="cite" cite="mid:01102912352504.01063@marvin">
            <pre wrap=""><br><br>Amon.<br>--<br><a class="moz-txt-link-freetext" href="http://www.rsbac.org">http://www.rsbac.org</a><br>-<br>To unsubscribe from the rsbac list, send a mail to<br><a class="moz-txt-link-abbreviated" href="mailto:majordomo@rsbac.org">majordomo@rsbac.org</a> with<br>unsubscribe rsbac<br>as single line in the body.<br></pre>
            </blockquote>
            <br>
            <br>
            </body>
            </html>

--------------000605030803050009020406--

-
To unsubscribe from the rsbac list, send a mail to
majordomo@rsbac.org with
unsubscribe rsbac
as single line in the body.

Next Article (by Author): Re: NSA - Spook Linux Stephen
Previous Article (by Author): Re: /etc protection Stanislav Ievlev
Top of Thread: 1.2.0-pre2 - first tests Stanislav Ievlev
Articles sorted by: [Date] [Author] [Subject]


Go to Compuniverse LWGate Home Page.