Re: FreeBSD Security in Multiuser Environments
In freebsd-questions Digest, Vol 408, Issue 10, Message: 5
On Sat, 31 Mar 2012 21:05:00 +0700 Erich Dollansky
erichfreebsdl...@ovitrap.com wrote:
On Saturday 31 March 2012 20:26:14 Julian H. Stacey wrote:
[..]
Da Rock wrote:
On 03/31/12 17:46, Julian H. Stacey wrote:
[..]
schu...@ime.usp.br wrote:
Hello,
I would like to raise a discussion about the security features
of FreeBSD as a whole and how they might be employed to actually
derive some meaningful guarantees.
We have a list specialy for freebsd-security@. Please use it.
I thought this to be sensible advice. Before seeing that I'd thought of
copying it to rwatson@ who I figured might take an interest due to his
involvement with Capsicum, acl(3) and such, but he certainly reads that
list anyway (and more than likely, not this one :)
Hang on, hold the phone: The security list (specifically) is for
security announcements. At least that what it said when I subscribed to
it...
Wrong.
Correct :)
For list of mail lists see:
http://lists.freebsd.org/mailman/listinfo
Specifically:
freebsd-secur...@freebsd.org
http://lists.freebsd.org/mailman/listinfo/freebsd-security
freebsd-security-notificati...@freebsd.org
http://lists.freebsd.org/mailman/listinfo/freebsd-security-notifications
this sounds very confusing for people who have simple question:
'General system administrator questions of an FAQ nature are
off-topic for this list, but the creation and maintenance of a FAQ is
on-topic. Thus, the submission of questions (with answers) for
inclusion into the FAQ is welcome. Such question/answer sets should
be clearly marked as (at least FAQ submission) such in the subject.
'
schultz' post was nothing in the way of an FAQ issue, but a request for
discussion of a wide range of system security issues, far indeed from a
'simple question'. Had you posted the two paragraphs before the one you
quote above, this may have been a little clearer. To wit:
This is a technical discussion list covering FreeBSD security issues.
The intention is for the list to contain a high-signal, low-noise
discussion of issues affecting the security of FreeBSD.
Welcome topics include Cryptography (as it relates to FreeBSD), OS bugs
that affect security, and security design issues. Denial-of-service
(DoS) issues are less important than problems that allow an attacker to
achieve elevated privelige, but are still on-topic.
This sounds that 'schultz' would be wrong there.
Not at all Erich, quite the opposite in my view; as someone who's been
subscribed to freebsd-security@ for 12 or so years, I look forward to
seeing informed responses to some of schultz' issues. In any event,
{s,}he promptly took Julian's advice to post it there, where one aspect
has already attracted responses from des@ and pjd@
The best way to get a good sense of what issues are acceptible and/or
useful topics for which lists, without having to subscribe, is to browse
a list's archives for several months. Works for me. In this case try:
http://lists.freebsd.org/pipermail/freebsd-security/
cheers, Ian
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: FreeBSD Security in Multiuser Environments
On 04/02/12 17:48, Ian Smith wrote: In freebsd-questions Digest, Vol 408, Issue 10, Message: 5 On Sat, 31 Mar 2012 21:05:00 +0700 Erich Dollanskyerichfreebsdl...@ovitrap.com wrote: On Saturday 31 March 2012 20:26:14 Julian H. Stacey wrote: [..] Da Rock wrote: On 03/31/12 17:46, Julian H. Stacey wrote: [..] schu...@ime.usp.br wrote: Hello, I would like to raise a discussion about the security features of FreeBSD as a whole and how they might be employed to actually derive some meaningful guarantees. We have a list specialy for freebsd-security@. Please use it. I thought this to be sensible advice. Before seeing that I'd thought of copying it to rwatson@ who I figured might take an interest due to his involvement with Capsicum, acl(3) and such, but he certainly reads that list anyway (and more than likely, not this one :) Hang on, hold the phone: The security list (specifically) is for security announcements. At least that what it said when I subscribed to it... Wrong. Correct :) So thats turn left, right? Clear as mud now... :) For list of mail lists see: http://lists.freebsd.org/mailman/listinfo Specifically: freebsd-secur...@freebsd.org http://lists.freebsd.org/mailman/listinfo/freebsd-security freebsd-security-notificati...@freebsd.org http://lists.freebsd.org/mailman/listinfo/freebsd-security-notifications this sounds very confusing for people who have simple question: 'General system administrator questions of an FAQ nature are off-topic for this list, but the creation and maintenance of a FAQ is on-topic. Thus, the submission of questions (with answers) for inclusion into the FAQ is welcome. Such question/answer sets should be clearly marked as (at least FAQ submission) such in the subject. ' schultz' post was nothing in the way of an FAQ issue, but a request for discussion of a wide range of system security issues, far indeed from a 'simple question'. Had you posted the two paragraphs before the one you quote above, this may have been a little clearer. To wit: This is a technical discussion list covering FreeBSD security issues. The intention is for the list to contain a high-signal, low-noise discussion of issues affecting the security of FreeBSD. I think that has clarified things sufficiently now. Looks like I should subscribe to that list too. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: FreeBSD Security in Multiuser Environments
Hello. 2012/03/30 22:44:16 -0300 schu...@ime.usp.br = To freebsd-questions@freebsd.org : P.S.: If you want to attain desktop security, matters get even more complicated. If anyone is interested, I can discuss what I did there (basically virtual X servers and building ports as regular users). Sure I am interested. I myself try to run Xorg server in a chroot and its clients from a different jail(s) via tcp on lo0. Trouble still is I can't get my VT ttyvXs because of that strange 'console ownership' stuff. Also, thanks for Capsicum, it sure is useful. Who is that? -- Peter Vereshagin pe...@vereshagin.org (http://vereshagin.org) pgp: A0E26627 ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: FreeBSD Security in Multiuser Environments
On 01/04/2012 09:47, Peter Vereshagin wrote: Also, thanks for Capsicum, it sure is useful. Who is that? Robert Watson, Jonathan Anderson and Ben Laurie are the principle 'who' behind Capsicum. Now, if you'ld asked 'What is that?' I'd've pointed you towards https://www.cl.cam.ac.uk/research/security/capsicum/ It's a lightweight OS capability and sandbox framework, or in other words a way of enforcing restrictions on what objects -- particularly those built from foreign data eg. javascript in web pages -- can modify or access on your local system. Cheers, Matthew -- Dr Matthew J Seaman MA, D.Phil. PGP: http://www.infracaninophile.co.uk/pgpkey signature.asc Description: OpenPGP digital signature
Re: FreeBSD Security in Multiuser Environments
Hi, Reference: From: schu...@ime.usp.br Date: Fri, 30 Mar 2012 22:44:16 -0300 Message-id: 20120330224416.13643xk4rsfd2...@webmail.ime.usp.br schu...@ime.usp.br wrote: Hello, I would like to raise a discussion about the security features of FreeBSD as a whole and how they might be employed to actually derive some meaningful guarantees. We have a list specialy for freebsd-security@. Please use it. Cheers, Julian -- Julian Stacey, BSD Unix Linux C Sys Eng Consultants Munich http://berklix.com Reply below not above, cumulative like a play script, indent with . Format: Plain text. Not HTML, multipart/alternative, base64, quoted-printable. Mail from @yahoo dumped @berklix. http://berklix.org/yahoo/ ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: FreeBSD Security in Multiuser Environments
On 03/31/12 17:46, Julian H. Stacey wrote: Hi, Reference: From: schu...@ime.usp.br Date: Fri, 30 Mar 2012 22:44:16 -0300 Message-id: 20120330224416.13643xk4rsfd2...@webmail.ime.usp.br schu...@ime.usp.br wrote: Hello, I would like to raise a discussion about the security features of FreeBSD as a whole and how they might be employed to actually derive some meaningful guarantees. We have a list specialy for freebsd-security@. Please use it. Hang on, hold the phone: The security list (specifically) is for security announcements. At least that what it said when I subscribed to it... ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: FreeBSD Security in Multiuser Environments
Hi, Reference: From: Da Rock freebsd-questi...@herveybayaustralia.com.au Date: Sat, 31 Mar 2012 21:25:37 +1000 Message-id: 4f76e9b1.5040...@herveybayaustralia.com.au Da Rock wrote: On 03/31/12 17:46, Julian H. Stacey wrote: Hi, Reference: From: schu...@ime.usp.br Date: Fri, 30 Mar 2012 22:44:16 -0300 Message-id:20120330224416.13643xk4rsfd2...@webmail.ime.usp.br schu...@ime.usp.br wrote: Hello, I would like to raise a discussion about the security features of FreeBSD as a whole and how they might be employed to actually derive some meaningful guarantees. We have a list specialy for freebsd-security@. Please use it. Hang on, hold the phone: The security list (specifically) is for security announcements. At least that what it said when I subscribed to it... Wrong. For list of mail lists see: http://lists.freebsd.org/mailman/listinfo Specifically: freebsd-secur...@freebsd.org http://lists.freebsd.org/mailman/listinfo/freebsd-security freebsd-security-notificati...@freebsd.org http://lists.freebsd.org/mailman/listinfo/freebsd-security-notifications Cheers, Julian -- Julian Stacey, BSD Unix Linux C Sys Eng Consultants Munich http://berklix.com Reply below not above, cumulative like a play script, indent with . Format: Plain text. Not HTML, multipart/alternative, base64, quoted-printable. Mail from @yahoo dumped @berklix. http://berklix.org/yahoo/ ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: FreeBSD Security in Multiuser Environments
Hi, On Saturday 31 March 2012 20:26:14 Julian H. Stacey wrote: Hi, Reference: From: Da Rock freebsd-questi...@herveybayaustralia.com.au Date: Sat, 31 Mar 2012 21:25:37 +1000 Message-id: 4f76e9b1.5040...@herveybayaustralia.com.au Da Rock wrote: On 03/31/12 17:46, Julian H. Stacey wrote: Hi, Reference: From:schu...@ime.usp.br Date:Fri, 30 Mar 2012 22:44:16 -0300 Message-id: 20120330224416.13643xk4rsfd2...@webmail.ime.usp.br schu...@ime.usp.br wrote: Hello, I would like to raise a discussion about the security features of FreeBSD as a whole and how they might be employed to actually derive some meaningful guarantees. We have a list specialy for freebsd-security@. Please use it. Hang on, hold the phone: The security list (specifically) is for security announcements. At least that what it said when I subscribed to it... Wrong. For list of mail lists see: http://lists.freebsd.org/mailman/listinfo Specifically: freebsd-secur...@freebsd.org http://lists.freebsd.org/mailman/listinfo/freebsd-security freebsd-security-notificati...@freebsd.org http://lists.freebsd.org/mailman/listinfo/freebsd-security-notifications this sounds very confusing for people who have simple question: 'General system administrator questions of an FAQ nature are off-topic for this list, but the creation and maintenance of a FAQ is on-topic. Thus, the submission of questions (with answers) for inclusion into the FAQ is welcome. Such question/answer sets should be clearly marked as (at least FAQ submission) such in the subject. ' This sounds that 'schultz' would be wrong there. Erich ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
FreeBSD Security in Multiuser Environments
Hello,
I would like to raise a discussion about the security features
of FreeBSD as a whole and how they might be employed to actually
derive some meaningful guarantees.
I have found myself administering a system with many potentially
untrusted users. Furthermore, some users do not trust some of the
programs they run and are thus allowed to ask for some slave
accounts. A slave account is a user account accessible only to
root and the master user. This can lead to a hierachy of authority.
Also, each account has potentially confidential data that may be
accessed only by the account itself and its ancestor accounts. This
includes when a user is logged on and what the user is running.
Finally, the system must always be up so no user untrusted by root
may trash it.
This is a pretty harsh set of restrictions and is almost unmanageable.
However, I have taken three steps to ensure security: base system
hardening, using sudo for privilege granting and using rctl(8) for
resource accounting and control. Gathering enough information in these
three areas has been an ongoing task for almost half a year, and I
would like to discuss some problems of my approach.
In terms of system hardening, I have:
* Encrypted the whole (except /boot) system with geli(8)
(HMAC/SHA256 and AES-XTS). It is not as nice and much slower
than proper filesystem-level checksumming but it is what
FreeBSD provides (ZFS is too unstable).
* Disabled useless and potentially dangerous services: cron, devd
and sendmail.
* Removed every setuid bit. The system works even then.
* Hardened /dev: every non necessary device has had the 0007 bits
stripped. Optional groups were created (e.g. audio, mixer and mic
for devices /dev/{mixer,dsp,audio}*).
* Hardened the sysctls:
- security.bsd.see_other_uids=0: Users can only see own processes.
- security.bsd.unprivileged_proc_debug=0
- security.bsd.unprivileged_read_msgbuf=0: The log is considered
sensitive information.
- security.bsd.hardlink_check_uid=1: Avoid hardlinks to old SUID
binaries.
- kern.log_console_output=0
- kern.coredump=0
- vm.overcommit=1: This avoids retarded Linux-like behaviour on
OOM conditions.
* Changed permissions on /root to 0700: root deserves privacy.
* A boot script changes some permissions:
- /var/log to 0750: the logs are considered sensitive information.
- /var/run/dmesg.boot to 0640: this is also sensitive information.
* Added a group sudoers and made sudo setuid only to users in
sudoers: would have avoided trouble with recent sudo exploit if
only trusted users have slaves.
As for using sudo to grant privilege, for each master-slave
relationship between users u and v, I have added a line like
u ALL = (v) NOPASSWD: ALL to /etc/sudoers. Then the user u is
supposed to become v by issuing sudo -i -u v and to execute a
command as v by issuing sudo -i -u v
It is worth noticing that sudo closes all file descriptors greater than
or equal to 3. It is important not to let your pseudo-terminal leak
through file descriptors 0, 1 and 2 if you have a shell connected to
it. Also, the -i is mandatory because otherwise a file descriptor
open at directory . is leaked via the cwd file descriptor. I
believe this is enough, but since this is not properly documented, I
am not sure.
As for resource limiting via rctl(8), for each user u root does not
trust, I have added three rules:
* user:u:vmemoryuse:deny=MEM
* user:u:maxproc:deny=PROCS
* user:u:pseudoterminals:deny=0
Here MEM and PROCS are limits on total virtual memory usage and
total occupied entries in the process table for process u,
respectively. Furthermore, I never give access to pseudo-terminals to
untrusted users because all sessions are started from ssh or ptys of
trusted users. Also, ptys must be available otherwise trusted users can
not work on the machine. Finally, I have noticed rctl -u user:u
reports a single pty open for user u no matter how many open ptys u has
(except of course if u has no open pty, in which case 0 is reported).
One naively would expect these restrictions to be enough to prevent
abuse (trashing or DoS) as long as the sum of the MEM values (rounded
up to page size) is less than or equal to the total physical memory
plus swap space less the system (and trusted users') memory usage and
the sum of the PROC values is less than the process table size minus
the number of trusted processes. I sincerely do not know if this is the
case.
However, using vmemoryuse as a limit is overkill: it counts the total
mapped pages, not the total anonymous pages, which are the ones that
actually take resources. Of course, this assumes the memory management
data structures (including the page table) are accounted as anonymous
memory of the corresponding process, since it is easy (especially on
amd64), to map pages sparsely to greatly increase the size of the
page table. However, I do not know if this assumption holds on
