Re: Security related questions
On Tuesday 30 March 2004 09:07 am, [EMAIL PROTECTED] wrote: could anyone explain some examples of setting up a restricted group for limiting users? using chmod and chown.. i've had a little luck, but not overall. - Original Message - From: Marc Spitzer [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, March 29, 2004 6:23 PM Subject: Re: Security related questions On Mon, 29 Mar 2004 13:58:06 +0200 (CEST) Kovács Péter [EMAIL PROTECTED] wrote: Hi all, I have some FreeBSD specific questions, that I can't solve. 1. How can I set a user profile to execute only specific commands/programs? Like in Trusted Solaris: Execution Profiles. There is a project for this, at least 1, but the name escapes me at the moment. I saw it on sourceforge Are you perhaps referring to TrustedBSD? http://www.trustedbsd.org/ -Mark ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
SSH issues with 4.9 stable (key_verify failed for server_host_key)
I upgraded to 4.9 stable from 4.9 release and now have difficulty connecting via ssh to hosts. The error I get is: key_verify failed for server_host_key If I modify the sshd_config for the server I am connecting to and change to the following, it works: Protocol 2 # HostKey for protocol version 1 #HostKey /etc/ssh/ssh_host_key # HostKeys for protocol version 2 HostKey /etc/ssh/ssh_host_rsa_key HostKey /etc/ssh/ssh_host_dsa_key ssh verbose dump: [EMAIL PROTECTED] daren]$ssh -v puff OpenSSH_3.8p1, SSH protocols 1.5/2.0, OpenSSL 0.9.7c-p1 30 Sep 2003 debug1: Reading configuration data /etc/ssh/ssh_config debug1: Connecting to puff [x.x.x.x] port 22. debug1: Connection established. debug1: identity file /home/daren/.ssh/identity type -1 debug1: identity file /home/daren/.ssh/id_rsa type 1 debug1: identity file /home/daren/.ssh/id_dsa type -1 debug1: Remote protocol version 1.99, remote software version OpenSSH_3.5p1 Free BSD-20030924 debug1: match: OpenSSH_3.5p1 FreeBSD-20030924 pat OpenSSH* debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_3.8p1 debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug1: kex: server-client aes128-cbc hmac-md5 none debug1: kex: client-server aes128-cbc hmac-md5 none debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(102410248192) sent debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP debug1: SSH2_MSG_KEX_DH_GEX_INIT sent debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY debug1: Host 'puff' is known and matches the DSA host key. debug1: Found key in /home/daren/.ssh/known_hosts:8 debug1: ssh_dss_verify: signature incorrect key_verify failed for server_host_key [EMAIL PROTECTED] daren]$ I did try removing the known_hosts entry, but it had no effect: [EMAIL PROTECTED] .ssh]$mv known_hosts known_hosts.bak [EMAIL PROTECTED] .ssh]$ssh -v puff OpenSSH_3.8p1, SSH protocols 1.5/2.0, OpenSSL 0.9.7c-p1 30 Sep 2003 debug1: Reading configuration data /etc/ssh/ssh_config debug1: Connecting to puff [x.x.x.x] port 22. debug1: Connection established. debug1: identity file /home/daren/.ssh/identity type -1 debug1: identity file /home/daren/.ssh/id_rsa type 1 debug1: identity file /home/daren/.ssh/id_dsa type -1 debug1: Remote protocol version 1.99, remote software version OpenSSH_3.5p1 Free BSD-20030924 debug1: match: OpenSSH_3.5p1 FreeBSD-20030924 pat OpenSSH* debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_3.8p1 debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug1: kex: server-client aes128-cbc hmac-md5 none debug1: kex: client-server aes128-cbc hmac-md5 none debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(102410248192) sent debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP debug1: SSH2_MSG_KEX_DH_GEX_INIT sent debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY The authenticity of host 'puff (x.x.x.x)' can't be established. DSA key fingerprint is f0:b5:90:fd:92:0d:4a:b6:87:13:45:63:72:a1:49:aa. Are you sure you want to continue connecting (yes/no)? yes Warning: Permanently added 'puff,x.x.x.x' (DSA) to the list of known hosts. debug1: ssh_dss_verify: signature incorrect key_verify failed for server_host_key [EMAIL PROTECTED] .ssh]$ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Serious bug in vinum?
On Tuesday, 30 March 2004 at 14:37:00 +0200, Lukas Ertl wrote:
On Fri, 26 Mar 2004, Joao Carlos Mendes Luis wrote:
I think this should be like:
if (plex-state plex_corrupt) { /* something accessible,
*/
Or, in other words, volume state is up only if plex state is degraded
or better.
You are right, this is a bug,
No, see my reply.
The correct solution, of course, is to check if the data is valid
before changing the volume state, but turn might turn out to be a
very complex check.
Well, the minimum correct solution is to return an error if somebody
tries to access the inaccessible part of the volume. That should
happen, and I'm confused that it doesn't appear to be doing so in this
case.
On Tuesday, 30 March 2004 at 11:07:55 -0300, Joo Carlos Mendes Lus wrote:
Greg 'groggy' Lehey wrote:
On Tuesday, 30 March 2004 at 0:32:38 -0300, Joo Carlos Mendes Lus wrote:
Basically, this is a feature and not a bug. A plex that is corrupt is
still partially accessible, so we should allow access to it. If you
have two striped plexes both striped between two disks, with the same
stripe size, and one plex starts on the first drive, and the other on
the second, and one drive dies, then each plex will lose half of its
data, every second stripe. But the volume will be completely
accessible.
A good idea if you have both stripe and mirror, to avoid discarding the
whole disk. But, IMHO, if some part of the disk is inacessible, the volume
should go down, and IFF the operator wants to try recovery, should use the
setstate command. This is the safe state.
setstate is not safe. It bypasses a lot of consistency checking.
One possibility would be:
1. Based on the plex states, check if all of the volume is still
accessible.
2. If not, take the volume into a flaky state.
3. *Somehow* ensure that the volume can't be accessed again as a file
system until it has been remounted.
4. Refuse to remount the file system without the -f option.
The last two are outside the scope of Vinum, of course.
Discussion?
--
Note: I discard all HTML mail unseen.
Finger [EMAIL PROTECTED] for PGP public key.
See complete headers for address and phone numbers.
pgp0.pgp
Description: PGP signature
Re: Ps(1) Restricting Command Lines
[EMAIL PROTECTED] said: This is my fault. Fix committed. Sorry for the mess and thank you for your report. I just finished upgrading to STABLE as of 0800 GMT today. Ps -ax is back to working as I expected. Thanks to all for the help. -- M/S 258-5|1024-bit PGP fingerprint:|[EMAIL PROTECTED] NASA Ames Research Center| 41 B0 89 0A 8F 94 6C 59| (650) 604-4416 Moffett Field, CA 94035-1000| 7C 80 10 20 25 C7 2F E6|FAX: (650) 604-4377 Not an official NASA position. You can't even be certain who sent this! ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Serious bug in vinum?
Greg 'groggy' Lehey wrote:
On Tuesday, 30 March 2004 at 14:37:00 +0200, Lukas Ertl wrote:
On Fri, 26 Mar 2004, Joao Carlos Mendes Luis wrote:
I think this should be like:
if (plex-state plex_corrupt) { /* something accessible, */
Or, in other words, volume state is up only if plex state is degraded
or better.
You are right, this is a bug,
No, see my reply.
I think maybe is the best answer here.
The correct solution, of course, is to check if the data is valid
before changing the volume state, but turn might turn out to be a
very complex check.
Well, the minimum correct solution is to return an error if somebody
tries to access the inaccessible part of the volume. That should
happen, and I'm confused that it doesn't appear to be doing so in this
case.
On Tuesday, 30 March 2004 at 11:07:55 -0300, Joo Carlos Mendes Lus wrote:
Greg 'groggy' Lehey wrote:
On Tuesday, 30 March 2004 at 0:32:38 -0300, Joo Carlos Mendes Lus wrote:
Basically, this is a feature and not a bug. A plex that is corrupt is
still partially accessible, so we should allow access to it. If you
have two striped plexes both striped between two disks, with the same
stripe size, and one plex starts on the first drive, and the other on
the second, and one drive dies, then each plex will lose half of its
data, every second stripe. But the volume will be completely
accessible.
A good idea if you have both stripe and mirror, to avoid discarding the
whole disk. But, IMHO, if some part of the disk is inacessible, the volume
should go down, and IFF the operator wants to try recovery, should use the
setstate command. This is the safe state.
setstate is not safe. It bypasses a lot of consistency checking.
That's why it should be done only by a human operator, and only after
checking the physical disk. I use setstate frequently, when I have my wizard
hat on, but I know the consequences of doing that. If I have someone watching I
carefully explain then to *not* repeat that. ;-)
One possibility would be:
1. Based on the plex states, check if all of the volume is still
accessible.
2. If not, take the volume into a flaky state.
This is easy if the volume is composed of a single plex (my case, and the
case of most people who needs only a big and unsafe disk. Where unsafe means
a disk available or not available, and not half a disk. At least for me.
If the volume has more than one plex, then you could think of an algoritm
that explores this redundancy.
But, IMO, a disk with half of it unavailable is hardly an up and ok one.
Also note that, instead of turning the whole subdisk stale when a single
I/O fails, the error could be passed above. But, also, this only works with
single plex stripe or concat configurations.
3. *Somehow* ensure that the volume can't be accessed again as a file
system until it has been remounted.
4. Refuse to remount the file system without the -f option.
The last two are outside the scope of Vinum, of course.
And again violates the layering aproach. I thought newfs -v has been enough...
The first time I used vinum I was happilly thinking that I would mix 4
whole disks (except for boot and swap partitions, of course) and create a new
pseudo disk, in which I would again disklabel it, and repartition for expected
use. Say, for example, that I want to have /var and /usr on different
partitions, but I want both with mirroring. With real world vinum I need to
create 2 vinum partitions on real disks, and have 2 vinum volumes.
AFAIK, -current and GEOM fixes this, right? My last experience with
RaidFrame was a panic one, since the disk creation. But I must confess I did
not try that hard, since vinum and -stable was working for me. I am not a
-current hacker for a long time now.
Greg, I like vinum, and I use it since its release in FreeBSD. Before that
I have used ccd(4). When 5.x is stable, I will use GEOM, vinum or raidframe.
But I really think *ix is great for it's reusability, recursivity and modularity
and vinum breaks this. If vinum creates a virtual disk, it should behave like a
real disk.
Jonny
--
João Carlos Mendes Luís - Networking Engineer - [EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
