Bug 104403
| Summary: | man security should mention that the usage of the X Window Systen is only possible with kern.securitylevel=-1 | ||
|---|---|---|---|
| Product: | Documentation | Reporter: | Dr. Markus Waldeck <waldeck> |
| Component: | Books & Articles | Assignee: | Giorgos Keramidas <keramida> |
| Status: | Closed FIXED | ||
| Severity: | Affects Only Me | ||
| Priority: | Normal | ||
| Version: | Latest | ||
| Hardware: | Any | ||
| OS: | Any | ||
|
Description
Dr. Markus Waldeck
2006-10-14 10:30:32 UTC
Responsible Changed From-To: freebsd-bugs->freebsd-doc This is a docs, not misc, PR. I don't think the security manpage is the right place for this. Raising securelevel can prevent a lot of things from working, but we can't try to document them all in the manpage. This issue is already mentioned in the FAQ; maybe a mention in the "X Window System" section of the handbook is worth considering. On 2006-10-14 09:29, "Dr. Markus Waldeck" <waldeck@gmx.de> wrote: > man security should mention that the usage of the X Window Systen is > only possible with kern.securitylevel=-1. > > With kern.securitylevel=0 or higher it is not possible to start X. You can still use `xdm' or a similar way of starting X11, because it will be started by init(8) before the securelevel is raised by the `/etc/rc.d/securelevel' script. I don't think this is worth mentioning in security(7), because we can't possibly document *ALL* the possible things that can fail with a bumped securelevel. On 2006-11-12 10:52, Niclas Zeising <lothrandil@n00b.apagnu.se> wrote: >Giorgos Keramidas wrote: >>> With kern.securitylevel=0 or higher it is not possible to start X. >> >> You can still use `xdm' or a similar way of starting X11, because >> it will be started by init(8) before the securelevel is raised by >> the `/etc/rc.d/securelevel' script. >> >> I don't think this is worth mentioning in security(7), because >> we can't possibly document *ALL* the possible things that can >> fail with a bumped securelevel. > > It it probably worth mentioning somewhere, as it will avoid some foot > shooting from unaware users. One can discuss though that if the extra > security provided by the security level is needed, maybe the system > shouldn't run X in the first place. I'm not sure. Should we also mention that you can't "installworld" with an elevated securelevel, because chflags may fail to work and cause problems? Should we also mention that not being able to change the firewall rules can be tricky, if you are testing your new firewall ruleset, and get locked out? There are *MANY* ways in which an elevated securelevel can turn around and bite you in the ass, but do we _really_ have to enumerate them all in mind-boggingly detail? ... in a single manpage? I really don't know. Giorgos Keramidas wrote:
> On 2006-11-12 10:52, Niclas Zeising <lothrandil@n00b.apagnu.se> wrote:
>> Giorgos Keramidas wrote:
>>>> With kern.securitylevel=0 or higher it is not possible to start X.
>>> You can still use `xdm' or a similar way of starting X11, because
>>> it will be started by init(8) before the securelevel is raised by
>>> the `/etc/rc.d/securelevel' script.
>>>
>>> I don't think this is worth mentioning in security(7), because
>>> we can't possibly document *ALL* the possible things that can
>>> fail with a bumped securelevel.
>> It it probably worth mentioning somewhere, as it will avoid some foot
>> shooting from unaware users. One can discuss though that if the extra
>> security provided by the security level is needed, maybe the system
>> shouldn't run X in the first place.
>
> I'm not sure.
>
> Should we also mention that you can't "installworld" with an elevated
> securelevel, because chflags may fail to work and cause problems?
> Should we also mention that not being able to change the firewall rules
> can be tricky, if you are testing your new firewall ruleset, and get
> locked out?
>
> There are *MANY* ways in which an elevated securelevel can turn around
> and bite you in the ass, but do we _really_ have to enumerate them all
> in mind-boggingly detail? ... in a single manpage?
>
> I really don't know.
>
I believe they should be documented somewhere, to avoid questions. But
you are right in that there are numerous consequences in raising secure
levels and that it might be a bit over the top to document them all.
Maybe I/we have to face the fact that it's too much and/or unnecessary
to document all consequences, and rely on that if a sysadmin feels the
need to raise the secure-level he knows what he's doing and the
consequences of doing so.
Maybe the biggest issues in raising secure-level should be mentioned,
but then again, who decides which those issues are?
Maybe it's best to leave the documentation regarding this as it is, and
give an answer whenever the issues pops up.
//Niclas
On 2006-11-12 14:55, Niclas Zeising <lothrandil@n00b.apagnu.se> wrote: >Giorgos Keramidas wrote: >> I'm not sure. >> >> Should we also mention that you can't "installworld" with an elevated >> securelevel, because chflags may fail to work and cause problems? >> Should we also mention that not being able to change the firewall >> rules can be tricky, if you are testing your new firewall ruleset, >> and get locked out? >> >> There are *MANY* ways in which an elevated securelevel can turn >> around and bite you in the ass, but do we _really_ have to enumerate >> them all in mind-boggingly detail? ... in a single manpage? >> >> I really don't know. > > I believe they should be documented somewhere, to avoid questions. I believe a manpage is not the right place for long, detailed, filled with gory details explanation of all the possible scenarios that can go wrong. I mean, there are ways to destroy a system with rm(1) too, but we don't have a list of funny, albeit dangerous "rm -fr /" scenarios in that manpage too. This sort of stuff, in my opinion, belongs to a tutorial style guide, i.e. something like a "Mini Guide for Security on FreeBSD". A manpage should be written as a 'reference' guide, but that's only *my* point of view. > But you are right in that there are numerous consequences in raising > secure levels and that it might be a bit over the top to document them > all. Maybe I/we have to face the fact that it's too much and/or > unnecessary to document all consequences, and rely on that if a > sysadmin feels the need to raise the secure-level he knows what he's > doing and the consequences of doing so. Maybe the biggest issues in > raising secure-level should be mentioned, but then again, who decides > which those issues are? EXACTLY! Picking up what level of detail we want to appear in a manpage is not easy if we let all the details about all potentially harmful scenarios go in. But if we treat manpages as 'reference' material, then the field is much much more clear. For example, we don't document all the different ways that fgets(3) can be abused in its manpage. We don't document all the potentially stupid ways to use scanf(3) in its manpage either. What we *do* write about in most manpages is a `reference guide'. > Maybe it's best to leave the documentation regarding this as it is, > and give an answer whenever the issues pops up. Or we can expand, extend and clean up the ``Security'' chapter of the Handbook, which has the potential and the purpose of being a guide which matches both a `tutorial' and `reference' styles (depending on how complete and nicely written the relevant sections are, of course). - Giorgos Giorgos Keramidas wrote: > On 2006-11-12 14:55, Niclas Zeising <lothrandil@n00b.apagnu.se> wrote: >> Giorgos Keramidas wrote: >>> I'm not sure. >>> >>> Should we also mention that you can't "installworld" with an elevated >>> securelevel, because chflags may fail to work and cause problems? >>> Should we also mention that not being able to change the firewall >>> rules can be tricky, if you are testing your new firewall ruleset, >>> and get locked out? >>> >>> There are *MANY* ways in which an elevated securelevel can turn >>> around and bite you in the ass, but do we _really_ have to enumerate >>> them all in mind-boggingly detail? ... in a single manpage? >>> >>> I really don't know. >> I believe they should be documented somewhere, to avoid questions. > > I believe a manpage is not the right place for long, detailed, filled > with gory details explanation of all the possible scenarios that can go > wrong. I mean, there are ways to destroy a system with rm(1) too, but > we don't have a list of funny, albeit dangerous "rm -fr /" scenarios in > that manpage too. I was not referring exclusively to a man page, rather that it should be documented somewhere. I agree with you that a man page is not the right place for this type of documentation, it is more of a reference. What the man page can have is a reference to documentation which discuss issues etc. in more detail so the user reading the man page knows where to look if the information wasn't enough. > > This sort of stuff, in my opinion, belongs to a tutorial style guide, > i.e. something like a "Mini Guide for Security on FreeBSD". A manpage > should be written as a 'reference' guide, but that's only *my* point of > view. Yup. > >> But you are right in that there are numerous consequences in raising >> secure levels and that it might be a bit over the top to document them >> all. Maybe I/we have to face the fact that it's too much and/or >> unnecessary to document all consequences, and rely on that if a >> sysadmin feels the need to raise the secure-level he knows what he's >> doing and the consequences of doing so. Maybe the biggest issues in >> raising secure-level should be mentioned, but then again, who decides >> which those issues are? > > EXACTLY! > > Picking up what level of detail we want to appear in a manpage is not > easy if we let all the details about all potentially harmful scenarios > go in. But if we treat manpages as 'reference' material, then the field > is much much more clear. True. Everybody just has to agree on that. I think it's a reasonable line to draw: Man pages are references, tutorials and other documents can go into more depth. Maybe we should state that somewhere? Or is that to overdo things? > > For example, we don't document all the different ways that fgets(3) can > be abused in its manpage. We don't document all the potentially stupid > ways to use scanf(3) in its manpage either. What we *do* write about in > most manpages is a `reference guide'. > >> Maybe it's best to leave the documentation regarding this as it is, >> and give an answer whenever the issues pops up. > > Or we can expand, extend and clean up the ``Security'' chapter of the > Handbook, which has the potential and the purpose of being a guide which > matches both a `tutorial' and `reference' styles (depending on how > complete and nicely written the relevant sections are, of course). I can see if I manage to hack some lines together regarding secure level, since I'm already in the security chapter mucking about. I just hope I realize when I'm in for too much ;) Regards! //Niclas Responsible Changed From-To: freebsd-doc->keramida Working with Tom on a Handbook patch for this. State Changed From-To: open->closed I have expanded a bit the description of kern.securelevel in the Handbook, including a note about X11 and installworld as part of the changes. Thenk you for noticing the original problem and reporting it to us :) keramida 2009-01-27 16:23:45 UTC
FreeBSD doc repository
Modified files:
en_US.ISO8859-1/books/handbook/security chapter.sgml
Log:
Expand a bit the description of kern.securelevel in the Handbook,
adding a note about possible problems with X11 or installworld
when securelevel >= 1.
PR: docs/104403
Submitted by: Dr. Markus Waldeck, waldeck (at) gmx.de
Reviewed by: trhodes
Revision Changes Path
1.333 +59 -19 doc/en_US.ISO8859-1/books/handbook/security/chapter.sgml
_______________________________________________
cvs-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/cvs-all
To unsubscribe, send any mail to "cvs-all-unsubscribe@freebsd.org"
|
