# kern_securelevel and Xorg



## Handy92 (Feb 9, 2016)

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


----------



## protocelt (Feb 9, 2016)

Handy92 said:


> I have problem with run securitylevel and Xorg. If is set to 3 then Xorg cant start.


AFAIK, that's expected behavior. You can't set the sysctl(8) kern.securelevel higher than 0 if you want to use x11/xorg.


----------



## Handy92 (Feb 10, 2016)

But I can set is using sysctl() and Xorg working normally.

```
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:~ #
```


----------



## Juha Nurmela (Feb 10, 2016)

Tried this also, just for fun, setting securelevel 2 after X was up. First hickup just appeared in mail from "periodic daily", 

```
SMART status:
Checking health of /dev/ada0: /dev/ada0: Operation not permitted
```

Juha


----------



## Handy92 (Feb 10, 2016)

After Xorg stand up is working well but how about startup?

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


----------



## leebrown66 (Feb 10, 2016)

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",
> 
> ```
> SMART status:
> ...


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.


----------



## Juha Nurmela (Feb 10, 2016)

kern.securelevel=2 also prevents burning DVDs. Level 1 might be okay for a slightly paranoid general surfboard.

Juha


----------



## leebrown66 (Feb 10, 2016)

Handy92 said:


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


11.3 explains why securelevel must be 0 to start X and offers an alternative: https://www.freebsd.org/doc/faq/x.html


----------



## Handy92 (Feb 10, 2016)

Thanks. Understood kern.securelevel is possible to put in /etc/rc.local?


----------



## leebrown66 (Feb 10, 2016)

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.


----------



## Handy92 (Feb 10, 2016)

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


----------



## leebrown66 (Feb 10, 2016)

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.


----------



## Juha Nurmela (Feb 11, 2016)

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


----------



## Handy92 (Feb 11, 2016)

.Xauthority or .Xininitrc?


----------



## ANOKNUSA (Feb 12, 2016)

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.


----------



## Handy92 (Feb 13, 2016)

> find: Xsetup: No such file or directory


----------



## protocelt (Feb 13, 2016)

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.


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.


----------



## Juha Nurmela (Feb 13, 2016)

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%


----------



## protocelt (Feb 13, 2016)

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.


 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,


Lol.


----------



## Maxnix (Feb 13, 2016)

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.


----------



## Handy92 (Feb 13, 2016)

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



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?


----------



## leebrown66 (Feb 13, 2016)

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?


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


----------



## Maxnix (Feb 13, 2016)

Handy92 said:


> IS basically configured to do that?


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?


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.


----------



## Maxnix (Feb 13, 2016)

leebrown66 said:


> or even  rm /usr/sbin/sshd to be *extremely* permanent


Well, this is REALLY extremely permanent!


----------



## Maxnix (Feb 13, 2016)

leebrown66 said:


> A regular user could still run the daemon on a non-privileged port.


This is a(nother) good reason to use a firewall to close unneeded ones.


----------



## Handy92 (Feb 13, 2016)

I want to clean system from all unused appss & cripts, When i will be need it I back it from LiveCD is no problem now for me , but I have problem with mount /home partition in /etc/fstab, some bugs, partition is no root or somethig like that, Xorg is crashing... Is topic for tomorrow, now I have some time for do that.

PS. I know if use `rm` is posiible to back file again. Best way is overwrite random data, using dd() or another program. 
`dd if=/dev/urandom of=/some/file`


----------

