Dynamically Enable Xwindows? - BSD

This is a discussion on Dynamically Enable Xwindows? - BSD ; I'm running OpenBSD 3.9 in console mode (no X-Windows). I have loaded the X-windows files from the 3.9 CD, but it doesn't run because the machdep aperture is not set to 2 at boot time. Can I set this variable ...

+ Reply to Thread
Page 1 of 2 1 2 LastLast
Results 1 to 20 of 25

Thread: Dynamically Enable Xwindows?

  1. Dynamically Enable Xwindows?

    I'm running OpenBSD 3.9 in console mode (no X-Windows).
    I have loaded the X-windows files from the 3.9 CD, but
    it doesn't run because the machdep aperture is not set
    to 2 at boot time. Can I set this variable just before
    I run startx or startkde and then reset the variable when
    I exit X-windows or must this be done at boot time?

    Thanks.

    --
    Using OpenBSD with or without X & KDE?
    http://dfeustel.home.mindspring.com

  2. Re: Dynamically Enable Xwindows?

    On Wed, 13 Sep 2006 14:22:10 +0000, dfeustel wrote:

    > I'm running OpenBSD 3.9 in console mode (no X-Windows).
    > I have loaded the X-windows files from the 3.9 CD, but
    > it doesn't run because the machdep aperture is not set
    > to 2 at boot time. Can I set this variable just before
    > I run startx or startkde and then reset the variable when
    > I exit X-windows or must this be done at boot time?


    Dave, take a look at xf86(4), where it states:

    "Access to the /dev/xf86 device is allowed when the sysctl(8)
    variable machdep.allowaperture is greater than or equal to 1.
    This variable (which has a default value of 0) can only be
    raised when the security level is less than or equal to 0, so it
    should be set in /etc/sysctl.conf."

    --
    --------
    E-mail will only get through if you use my first name before the @


  3. Re: Dynamically Enable Xwindows?

    Josh Grosse wrote:
    > On Wed, 13 Sep 2006 14:22:10 +0000, dfeustel wrote:
    >
    >> I'm running OpenBSD 3.9 in console mode (no X-Windows).
    >> I have loaded the X-windows files from the 3.9 CD, but
    >> it doesn't run because the machdep aperture is not set
    >> to 2 at boot time. Can I set this variable just before
    >> I run startx or startkde and then reset the variable when
    >> I exit X-windows or must this be done at boot time?

    >
    > Dave, take a look at xf86(4), where it states:
    >
    > "Access to the /dev/xf86 device is allowed when the sysctl(8)
    > variable machdep.allowaperture is greater than or equal to 1.
    > This variable (which has a default value of 0) can only be
    > raised when the security level is less than or equal to 0, so it
    > should be set in /etc/sysctl.conf."


    I did that and startx starts, but doesn't initialize properly.
    I get a graphics screen with an xterm window, but no color and
    no response to tty input.

    Also, possibly coincidentally, my internet access didn't work.
    I commented out the machine.aperture= line in /etc/sysctl.conf
    and rebooted, after which internet access worked again.

    Is there any other initialization required for X-windows?

    --
    Using OpenBSD with or without X & KDE?
    http://dfeustel.home.mindspring.com

  4. Re: Dynamically Enable Xwindows?

    On Wed, 13 Sep 2006 16:00:24 +0000, dfeustel wrote:

    > Josh Grosse wrote:
    >> On Wed, 13 Sep 2006 14:22:10 +0000, dfeustel wrote:
    >>
    >>> I'm running OpenBSD 3.9 in console mode (no X-Windows).
    >>> I have loaded the X-windows files from the 3.9 CD, but
    >>> it doesn't run because the machdep aperture is not set
    >>> to 2 at boot time. Can I set this variable just before
    >>> I run startx or startkde and then reset the variable when
    >>> I exit X-windows or must this be done at boot time?

    >>
    >> Dave, take a look at xf86(4), where it states:
    >>
    >> "Access to the /dev/xf86 device is allowed when the sysctl(8)
    >> variable machdep.allowaperture is greater than or equal to 1.
    >> This variable (which has a default value of 0) can only be
    >> raised when the security level is less than or equal to 0, so it
    >> should be set in /etc/sysctl.conf."

    >
    > I did that and startx starts, but doesn't initialize properly.
    > I get a graphics screen with an xterm window, but no color and
    > no response to tty input.
    >
    > Also, possibly coincidentally, my internet access didn't work.
    > I commented out the machine.aperture= line in /etc/sysctl.conf
    > and rebooted, after which internet access worked again.
    >
    > Is there any other initialization required for X-windows?


    No. But ... you've used X with OpenBSD before, in particular because
    you've asked many questions about X applications, X configuration, and KDE
    on misc@.

    If X was working before, but it is not now, then something isn't
    set right. For example, are you spelling machdep.allowaperture
    correctly? Are you using =1 when you should be using =2? Did you
    change your xorg.conf between then and now?

    Your network problem, I would think, has little to do with X, unless you
    are trying to use XDMCP to serve X over the network, and have it somehow
    misconfigured. But the default X config on OpenBSD does not use
    XDMCP. No matter how or what is damaging your network, diagnostic tools
    like tcpdump(8) and netstat(1) can tell you what's going on (or not)
    across your NICs the next time you have some sort of network trouble.

    --
    --------
    E-mail will only get through if you use my first name before the @


  5. Re: Dynamically Enable Xwindows?

    Dave, in your initial post, you wrote:

    > I have loaded the X-windows files from the 3.9 CD


    I assume this was done manually, *after* installation. Did
    you untar all five X filesets? Did you use the "p" option, so that they
    get the proper filemode settings?
    --
    --------
    E-mail will only get through if you use my first name before the @


  6. Re: Dynamically Enable Xwindows?

    Josh Grosse wrote:
    > Dave, in your initial post, you wrote:
    >
    >> I have loaded the X-windows files from the 3.9 CD

    >
    > I assume this was done manually, *after* installation.


    Actually, I had been running 3.9 ion my desktop without
    any X-windows files installed. I have been running 3.9
    *with* X-windows installed for a month or two on my laptop.
    I have Konqueror and its required KDE support files installed
    as well. I have seen no signs of gremlins on the laptop system,
    so I am now trying to upgrade my desktop system to be able to
    run Konqueror for a few websites.

    > Did you untar all five X filesets?


    I used the upgrade option of install in which all the X-windows
    files from the 3.9 cdrom were copied to the desktop system by the
    install script. But startx would not work, I think because
    machine.allowaperture was set = 0 by the original install.
    I'm not sure whether I set machine.allowaperture to 1 or to 2.
    From your previous post, 1 would not be high enough.
    I will try it again.

    > Did you use the "p" option, so that they
    > get the proper filemode settings?


    No. What command has the "p" option?

    --
    Using OpenBSD with or without X & KDE?
    http://dfeustel.home.mindspring.com

  7. Re: Dynamically Enable Xwindows?

    On Wed, 13 Sep 2006 21:02:44 +0000, dfeustel wrote:

    >> Did you use the "p" option, so that they
    >> get the proper filemode settings?

    >
    > No. What command has the "p" option?


    It is now academic, since you used the shell scripts, but
    the command I am referring to is tar(1), to preserver user and group id
    information on files that you extract from an archive.

    --
    --------
    E-mail will only get through if you use my first name before the @


  8. Re: Dynamically Enable Xwindows?

    dfeustel@mindspring.com wrote:
    > Actually, I had been running 3.9 ion my desktop without
    > any X-windows files installed. I have been running 3.9
    > *with* X-windows installed for a month or two on my laptop.
    > I have Konqueror and its required KDE support files installed
    > as well. I have seen no signs of gremlins on the laptop system,
    > so I am now trying to upgrade my desktop system to be able to
    > run Konqueror for a few websites.
    >
    > > Did you untar all five X filesets?

    >
    > I used the upgrade option of install in which all the X-windows
    > files from the 3.9 cdrom were copied to the desktop system by the
    > install script. But startx would not work, I think because
    > machine.allowaperture was set = 0 by the original install.
    > I'm not sure whether I set machine.allowaperture to 1 or to 2.
    > From your previous post, 1 would not be high enough.
    > I will try it again.


    the upgrade option does not extract xetc39.tgz. you must do this manually.

    # cd /
    # tar zxpf /tmp/xetc39.tgz

    > > Did you use the "p" option, so that they
    > > get the proper filemode settings?

    >
    > No. What command has the "p" option?


    tar(1), see above.

  9. Re: Dynamically Enable Xwindows?

    dfeustel@mindspring.com wrote:
    >
    > I used the upgrade option of install in which all the X-windows
    > files from the 3.9 cdrom were copied to the desktop system by the
    > install script. But startx would not work, I think because
    > machine.allowaperture was set = 0 by the original install.
    > I'm not sure whether I set machine.allowaperture to 1 or to 2.
    > From your previous post, 1 would not be high enough.
    > I will try it again.


    You can set the allowaperture to 1 or to 2 in /etc/sysctl.conf.
    In my experience, all recent drivers require allowaperture being
    set to "2" to get an acceptable use of the graphics card.

    Don't worry at all about the issues outlined by Mr. Duflot on
    his paper. Setting allowaperture to a value different from zero
    will only allow privilege scalation by lowering the secure level.
    For this scalation being effective, a cracker will need root
    privileges. In short, a cracker can make a *currently compromised*
    machine more vulnerable by lowering the secure level, but it is
    not a way to compromise a machine itself.

    Cheers,
    Igor.

  10. Re: Dynamically Enable Xwindows?


    dfeustel@mindspring.com wrote:
    > I'm running OpenBSD 3.9 in console mode (no X-Windows).
    > I have loaded the X-windows files from the 3.9 CD, but
    > it doesn't run because the machdep aperture is not set
    > to 2 at boot time. Can I set this variable just before
    > I run startx or startkde and then reset the variable when
    > I exit X-windows or must this be done at boot time?


    if you could set it to 2 at any time, what would be the point?


  11. Re: Dynamically Enable Xwindows?

    tedu wrote:
    >
    > dfeustel@mindspring.com wrote:
    >> I'm running OpenBSD 3.9 in console mode (no X-Windows).
    >> I have loaded the X-windows files from the 3.9 CD, but
    >> it doesn't run because the machdep aperture is not set
    >> to 2 at boot time. Can I set this variable just before
    >> I run startx or startkde and then reset the variable when
    >> I exit X-windows or must this be done at boot time?

    >
    > if you could set it to 2 at any time, what would be the point?


    I think that he believes that setting the aperture to 2 will open
    the system to attacks. That is not true, it only makes a system
    that has been currently compromised a bit easier to own, allowing
    a cracker to lower the secure level. As you, I believe that changing
    dynamically the value of aperture is not be possible. Never tried it,
    but if it were possible *any* i386-compatible system would be in
    risk even if it is not running a GUI. I suppose that a reboot
    will be required. In fact, as you asks, whay would be the point
    of setting the aperture to 0, 1, or 2 if it can be changed at any
    time? In fact, what will stop a cracker to change the value of
    aperture before lowering the securelevel? That is a very good point.

    Igor.

  12. Re: Dynamically Enable Xwindows?

    Igor Sobrado wrote:
    > dfeustel@mindspring.com wrote:
    >>
    >> I used the upgrade option of install in which all the X-windows
    >> files from the 3.9 cdrom were copied to the desktop system by the
    >> install script. But startx would not work, I think because
    >> machine.allowaperture was set = 0 by the original install.
    >> I'm not sure whether I set machine.allowaperture to 1 or to 2.
    >> From your previous post, 1 would not be high enough.
    >> I will try it again.

    >
    > You can set the allowaperture to 1 or to 2 in /etc/sysctl.conf.
    > In my experience, all recent drivers require allowaperture being
    > set to "2" to get an acceptable use of the graphics card.
    >
    > Don't worry at all about the issues outlined by Mr. Duflot on
    > his paper. Setting allowaperture to a value different from zero
    > will only allow privilege scalation by lowering the secure level.
    > For this scalation being effective, a cracker will need root
    > privileges. In short, a cracker can make a *currently compromised*
    > machine more vulnerable by lowering the secure level, but it is
    > not a way to compromise a machine itself.


    This is not actually true for most modern graphic cards. As Theo pointed
    out, modern graphic cards can do DMA.

    While the aperture mechanism makes sure that X cannot directly access
    main memory, it does not help all that much against indirect access...

    Joachim

  13. Re: Dynamically Enable Xwindows?

    jKILLSPAM.schipper@math.uu.nl wrote:
    >
    > This is not actually true for most modern graphic cards. As Theo pointed
    > out, modern graphic cards can do DMA.


    Indeed, modern graphic cards can do DMA over the entire system memory
    address space, I missed that point... what a nightmare!

    > While the aperture mechanism makes sure that X cannot directly access
    > main memory, it does not help all that much against indirect access...


    What cards is required for an indirect access to the system memory?
    Most of the machines I own have old cards... NeoMagic, Cirrus Logic,
    Chips and Technologies... manufactured between 1997 and 2000, are these
    cards vulnerable? Do they need to have processors that can run their
    own code like current NVIDIA and ATI cards?

    I am just curious, but it certainly sounds worse than expected.
    Until now, I supposed that it was ok having machines with aperture
    size zero in the perimeter of the networks. Again, I suppose that
    root access is required to exploit this vulnerability, but at least
    I supposed that the machines were protected when an X/Window server
    was not running.

    Best regards,
    Igor.

  14. Re: Dynamically Enable Xwindows?

    Igor Sobrado wrote:
    > jKILLSPAM.schipper@math.uu.nl wrote:
    >>
    >> This is not actually true for most modern graphic cards. As Theo pointed
    >> out, modern graphic cards can do DMA.

    >
    > Indeed, modern graphic cards can do DMA over the entire system memory
    > address space, I missed that point... what a nightmare!
    >
    >> While the aperture mechanism makes sure that X cannot directly access
    >> main memory, it does not help all that much against indirect access...

    >
    > What cards is required for an indirect access to the system memory?
    > Most of the machines I own have old cards... NeoMagic, Cirrus Logic,
    > Chips and Technologies... manufactured between 1997 and 2000, are these
    > cards vulnerable? Do they need to have processors that can run their
    > own code like current NVIDIA and ATI cards?


    No clue. Apparently, no-one else has, either, as this is the only
    response.

    > I am just curious, but it certainly sounds worse than expected.
    > Until now, I supposed that it was ok having machines with aperture
    > size zero in the perimeter of the networks. Again, I suppose that
    > root access is required to exploit this vulnerability, but at least
    > I supposed that the machines were protected when an X/Window server
    > was not running.


    If machdep.aperture=0, the machine is quite secure.

    Also, it's not *that* bad - if someone has root, you're already pretty
    much screwed, and kernel-level access is no more than one reboot away
    anyway.

    Joachim

  15. Re: Dynamically Enable Xwindows?

    jKILLSPAM.schipper@math.uu.nl wrote:
    > Igor Sobrado wrote:
    >>
    >> What cards is required for an indirect access to the system memory?
    >> Most of the machines I own have old cards... NeoMagic, Cirrus Logic,
    >> Chips and Technologies... manufactured between 1997 and 2000, are these
    >> cards vulnerable? Do they need to have processors that can run their
    >> own code like current NVIDIA and ATI cards?

    >
    > No clue. Apparently, no-one else has, either, as this is the only
    > response.


    Ok, thanks! I have some very old graphic cards that do not require
    even the allocation of an IRQ to them. In any case, I think that
    any (not so) modern graphic card is at risk. Will it make sense
    enabling X11 on older (plain VGA) cards? ...it is just that I do
    not want to drop OpenMotif on my desktop computer (this computer is
    an excellent workstation, a bit old P166 but with an fine 14" digital
    LCD display on it). On the other hand, no one of my servers have X.Org
    installed.

    >> I am just curious, but it certainly sounds worse than expected.
    >> Until now, I supposed that it was ok having machines with aperture
    >> size zero in the perimeter of the networks. Again, I suppose that
    >> root access is required to exploit this vulnerability, but at least
    >> I supposed that the machines were protected when an X/Window server
    >> was not running.

    >
    > If machdep.aperture=0, the machine is quite secure.


    Thanks! That is what I understand from the paper.

    > Also, it's not *that* bad - if someone has root, you're already pretty
    > much screwed, and kernel-level access is no more than one reboot away
    > anyway.


    Indeed... we can say that "changing the securelevel and rebooting the
    computer will certainly warn an authorized user" but stopping the X11
    server will be easily noticeable too. I agree with you, if someone
    has root access to the computer any possible damage is currently done.

    Cheers,
    Igor.

  16. Re: Dynamically Enable Xwindows?

    Igor Sobrado wrote:
    > jKILLSPAM.schipper@math.uu.nl wrote:
    >> Igor Sobrado wrote:
    >>>
    >>> What cards is required for an indirect access to the system memory?
    >>> Most of the machines I own have old cards... NeoMagic, Cirrus Logic,
    >>> Chips and Technologies... manufactured between 1997 and 2000, are these
    >>> cards vulnerable? Do they need to have processors that can run their
    >>> own code like current NVIDIA and ATI cards?

    >>
    >> No clue. Apparently, no-one else has, either, as this is the only
    >> response.

    >
    > Ok, thanks! I have some very old graphic cards that do not require
    > even the allocation of an IRQ to them. In any case, I think that
    > any (not so) modern graphic card is at risk. Will it make sense
    > enabling X11 on older (plain VGA) cards? ...it is just that I do
    > not want to drop OpenMotif on my desktop computer (this computer is
    > an excellent workstation, a bit old P166 but with an fine 14" digital
    > LCD display on it). On the other hand, no one of my servers have X.Org
    > installed.


    Again, I don't know much about graphic cards, let alone very old ones.

    Running X on your computer will not make *that* much of a security
    difference; certainly less than running, say, Firefox [1].

    >>> I am just curious, but it certainly sounds worse than expected.
    >>> Until now, I supposed that it was ok having machines with aperture
    >>> size zero in the perimeter of the networks. Again, I suppose that
    >>> root access is required to exploit this vulnerability, but at least
    >>> I supposed that the machines were protected when an X/Window server
    >>> was not running.

    >>
    >> If machdep.aperture=0, the machine is quite secure.

    >
    > Thanks! That is what I understand from the paper.
    >
    >> Also, it's not *that* bad - if someone has root, you're already pretty
    >> much screwed, and kernel-level access is no more than one reboot away
    >> anyway.

    >
    > Indeed... we can say that "changing the securelevel and rebooting the
    > computer will certainly warn an authorized user" but stopping the X11
    > server will be easily noticeable too. I agree with you, if someone
    > has root access to the computer any possible damage is currently done.


    Stopping the X11 server is not necessary to exploit the graphic card;
    injecting some additional code is sufficient, and this can be done
    without stopping it.

    There are some ways to limit root's powers, noticeably securelevels, but
    they tend not to work that well.

    Joachim

    [1] Which is in many ways a very good program, but it does have much
    more vulnerabilities than any other program I run on a typical desktop
    machine.

  17. Re: Dynamically Enable Xwindows?

    jKILLSPAM.schipper@math.uu.nl wrote:
    >
    > Again, I don't know much about graphic cards, let alone very old ones.
    >
    > Running X on your computer will not make *that* much of a security
    > difference; certainly less than running, say, Firefox [1].


    Firefox, as other browsers, speaks directly to a universe of mostly
    broken code that is usually unable to pass the W3 Consortium validation
    (in most cases it is too far from being acceptable). Not to mention
    the large amount of add-ons in the form of javascripts, flash and so on,
    added to make a useless URI look pretty. I am not surprised about
    the vulnerabilities related with something that is as open on its
    specifications as the languages and tools used in relation with the
    world-wide web.

    > Stopping the X11 server is not necessary to exploit the graphic card;
    > injecting some additional code is sufficient, and this can be done
    > without stopping it.


    Indeed, it is the base for injection attacks. I was just thinking
    on the simple example provided in the paper, that requires /dev/xf86
    to be available for opening.

    > There are some ways to limit root's powers, noticeably securelevels, but
    > they tend not to work that well.


    I certainly do not trust a lot on securelevels. A secure level can
    be easily changed (after a reboot at most) and usually restrict the
    ability of managers to monitor the servers (e.g., reading S.M.A.R.T.
    reports)

    > [1] Which is in many ways a very good program, but it does have much
    > more vulnerabilities than any other program I run on a typical desktop
    > machine.


    It seems that both Coverity and the code auditing being done
    are discovering a lot of bugs in firefox right now. We have a new
    release each two weeks or so fixing some important bugs. I hope
    that this code auditing process will make firefox as secure as
    typical desktop applications soon.

    Cheers,
    Igor.

  18. Re: Dynamically Enable Xwindows?

    Igor Sobrado wrote:
    > jKILLSPAM.schipper@math.uu.nl wrote:
    >> (Firefox) is in many ways a very good program, but it does have much
    >> more vulnerabilities than any other program I run on a typical
    >> desktop machine.

    >
    > It seems that both Coverity and the code auditing being done
    > are discovering a lot of bugs in firefox right now. We have a new
    > release each two weeks or so fixing some important bugs. I hope
    > that this code auditing process will make firefox as secure as
    > typical desktop applications soon.


    Nah, fat chance. Firefox is big, and not all of its developers are
    security-conscious enough. Coverity appears to be quite good, and will
    likely find quite a few bugs; but I'll not be convinced those are the
    last.

    Though some context helps here - since I've booted this machine 30
    minutes ago (it's a laptop), I've run rtin, dillo, ssh, svn, some random
    shell commands, and now mutt and vim. Of those, the latter is the only
    one I've ever had to upgrade due to security problems.

    Joachim

  19. Re: Dynamically Enable Xwindows?

    jKILLSPAM.schipper@math.uu.nl wrote:
    >
    > Nah, fat chance. Firefox is big, and not all of its developers are
    > security-conscious enough. Coverity appears to be quite good, and will
    > likely find quite a few bugs; but I'll not be convinced those are the
    > last.


    Agreed, Coverity shows some "possible" bugs in the code (of course,
    a security conscious programmer must manually audit each warning
    to see if it is a real bug). On the other hand, a security conscious
    programmer will not only make few bugs (making automatic auditing
    processes of the source code less important) but will also make few
    "undetectable" bugs.

    I fully agree with you, Firefox is too large and not all programmers
    working on that project are security conscious. It will never be
    as secure as a small project managed by security conscious programmers.

    > Though some context helps here - since I've booted this machine 30
    > minutes ago (it's a laptop), I've run rtin, dillo, ssh, svn, some random
    > shell commands, and now mutt and vim. Of those, the latter is the only
    > one I've ever had to upgrade due to security problems.


    Bugs can be found on places that are difficult to believe. I suppose
    that the bug you patched is related with the permissions or owners of
    files created using that editor. :-)

    I usually prefer staying at the software provided with the operating
    system. vim has a lot of nice extensions to vi, indeed, there is some
    people here, in the Department of Mathematics, using vim and it can be
    certainly highly customized (e.g., for TeX), but I prefer staying at
    something that is portable to any computer running Unix (i.e., plain vi).
    If it means "software written by the BSD development teams" (either
    FreeBSD, NetBSD or OpenBSD)... excellent! I usually trust on the
    software maintained by these teams. In any case, I try to minimize
    the amount of external software added to the system.

    A good friend of me observed some time ago that mutt was an excellent
    choice for security conscious users. I certainly believe it is a
    highly secure MUA... however on my computer, I am running nmh instead.
    I am interested in returning to mail/uuencode again, but the amount
    of violations to mail standards that are being accepted these days make
    returning to the original Unix mail system a real nightmare. MUAs are
    some of the few components of a Unix system that, sadly, must be replaced
    in most cases.

    Cheers,
    Igor.

  20. Re: Dynamically Enable Xwindows?

    Igor Sobrado wrote:



    > A good friend of me observed some time ago that mutt was an excellent
    > choice for security conscious users. I certainly believe it is a
    > highly secure MUA... however on my computer, I am running nmh instead.
    > I am interested in returning to mail/uuencode again, but the amount
    > of violations to mail standards that are being accepted these days make
    > returning to the original Unix mail system a real nightmare. MUAs are
    > some of the few components of a Unix system that, sadly, must be replaced
    > in most cases.


    What kinds of mail standards violations are you referring to above?

    Thanks,
    Dave Feustel
    --
    Using OpenBSD with or without X & KDE?
    http://dfeustel.home.mindspring.com

+ Reply to Thread
Page 1 of 2 1 2 LastLast