kern_securelevel and Xorg

Handy92

Handy92

I have problem with run securitylevel and Xorg. If is set to 3 then Xorg cant start. I read somewhere if I must load driver via /boot/loader.conf but i tried start at Vesa, and still do not work. Any body know what part must be load to run Intel HD3000
 
But I can set is using sysctl() and Xorg working normally.
Code: 
root@komputer:~ # sysctl kern.securelevel=3
kern.securelevel: -1 -> 3
root@komputer:~ # sysctl kern.securelevel=3
kern.securelevel: 3 -> 3
root@komputer:~ # sysctl kern.securelevel
kern.securelevel: 3
root@komputer:~ #
 
Tried this also, just for fun, setting securelevel 2 after X was up. First hickup just appeared in mail from "periodic daily",
Code: 
SMART status:
Checking health of /dev/ada0: /dev/ada0: Operation not permitted

Juha
 
After Xorg stand up is working well but how about startup?
Code: 
X server died during startup X server for display :0 cannot be started session disabled.

I use KDE4 and tried 1,2 and 3 stage, and tried too startx after loging. Nothing. I read Xorg log now...
 
Juha Nurmela said:
Tried this also, just for fun, setting securelevel 2 after X was up. First hickup just appeared in mail from "periodic daily",
Code: 
SMART status:
Checking health of /dev/ada0: /dev/ada0: Operation not permitted

Juha
Click to expand...
That's expected because smartctl needs to be able to write to the disk in order to command it to give up SMART data. securelevel(7) 2 precludes writing to the disk.
 
rc.conf may be a better choice, also may not make any difference. I think that should work. If you execute rcorder /etc/rc.d/*, you'll see the securelevel script is run after LOGIN and syscons which I would assume rely on the ttys already being setup.
Having said that I don't know where exactly the ttys are setup, so it's a bit of a guess.
 
I am sure if not. First start Xorg, and login is on KDM. If I set the securitylevel Xorg just do not start. I can start VESA from /boot/loader.conf but Xorg still want something... When I will find what is need maybe is good idea to compile it into kernel or something like that??
 
Have you tried turning xdm on in /etc/ttys?

Alternatively, you might just have to write a script, run from root, which temporarily sets securelevel to 0, executes X as a background task as the appropriate user, waits 2-3 seconds to give X time to do its thing, then raises securelevel back up to 2. That's not a pretty solution though.
 
There ought to be a file, Xsetup, which is run as root, just after Xserver has started. It's in some absurd place like /usr/local/share/kde4/config/kdm/, really long just to irritate people, exact path depends on the used displaymanager. Adding sysctl kern.securelevel=N there ought to work.

Juha
 
ANOKNUSA said:
read security(7). Fiddling with the securelevel sysctl on a desktop or laptop doesn't have any benefit I can see, and will make the system impractical to work with.
Click to expand...
Agreed. This is a bad idea IMHO. Xorg needs access the the I/O subsystem as well as kernel memory on FreeBSD. This is true on Linux IIRC as well, and on FreeBSD, setting kern.securelevel above the default prevents that and will cause various weird errors(one of them noted above by Juha Nurmela).

As far as I know, OpenBSD is the only operating system at this point of time that can successfully run Xorg devoid of root privileges.
 
Surprisingly few problems so far, I'm still on level 2 from the have-a-go experiment, and the only new thing to "report" is a failed tunefs -L randomlabel mmcsd0s2a.

I have steel bolts on my cheese door,
Juha

Edit: intel_backlight crippled, LCD brightness locked to 100%
 
Last edited:
Juha Nurmela said:
Surprisingly few problems so far, I'm still on level 2 from the have-a-go experiment, and the only new thing to "report" is a failed tunefs -L randomlabel mmcsd0s2a.
Click to expand...
That is actually kind of surprising, though you did set the security level after X was already up as opposed to before. I still wouldn't be surprised to see more mysterious oddities headed your way soon enough. :)

Juha Nurmela said:
I have steel bolts on my cheese door,
Click to expand...
Lol.
 
Handy92,
I don't use KDE, but I read that on Linux systems KDM's configuration files' directory is /etc/kde/kdm, so on FreeBSD it should be /usr/local/etc/kde/kdm. So the Xsetup file you are looking for should be there.
 
/usr/local/share/config/kdm/Xsetup

I just bad searching before. Thanks working :)
OpenBSD is the only operating system at this point of time that can successfully run Xorg devoid of root privileges.
Click to expand...

IS basically configured to do that?
I planed to migrate to OpenBSD but I am still newbie to use OpenBSD, so not yet.

And I have one more question, is little off topic... remove for example sshd from /etc/rc.d is enough to permanently disable this daemon?
 
Handy92 said:
And I have one more question, is little off topic... remove for example sshd from /etc/rc.d is enough to permanently disable this daemon?
Click to expand...
sshd_enable="NO" in /etc/rc.conf should be sufficient. Root should be the only user able to modify that file and if an unauthorised person gains root, well the game is over.

A regular user could still run the daemon on a non-privileged port. You could modify the flags of /usr/sbin/sshd so that only root could execute it (0600), or even rm /usr/sbin/sshd to be extremely permanent ;)
 
Handy92 said:
IS basically configured to do that?
Click to expand...
OpenBSD during installation asks the user if him intend to use X, then, if answered yes, sets the system variable machdep.allowaperture (inexistent on FreeBSD) to 2 or 1 (depending on platform) and stores it in /etc/sysctl.conf (just like FreeBSD does with its sysctl vars).
Handy92 said:
And I have one more question, is little off topic... remove for example sshd from /etc/rc.d is enough to permanently disable this daemon?
Click to expand...
You MUST NOT touch scripts in /etc/rc.d directory (unless you REALLY want to do that and know what you are doing). How leebrown66 said sshd_enable="NO" in /etc/rc.conf is enough.
Remeber: All configurations (enabling, disabling, flags...) for /etc/rc.d and /usr/local/etc/rc.d scripts had to be done in /etc/rc.conf file.
 
You must log in or register to reply here.
Back
Top